[os-engineering] FW: [os-infrastructure] Re: Model discussionboiled dry(er)

[Joe Abbate]

Chris Clark wrote:
> On 6/26/2008 9:04 AM, Alex Hanshaw wrote:
>>  ....Ray has put together a diagram of
>> model a) as a discussion point. I'm sure this list will see the detail
>> once some initial refinement has been made. OpenROAD are aware.
>>   
>
> This is now ready for prime time at 
> http://community.ingres.com/wiki/Community_Model I would like to 
> suggest a rule/guideline for this page, you only post what you know is 
> the proposal. Discussion should talk place in this list, phone, IM, 
> two tin cans and string. Avoiding cruft on the wiki page is going to 
> be useful.

This is not what I had in mind when I mentioned "use case stories".  
What I think is needed is perhaps a loose combination of "use case" 
(http://en.wikipedia.org/wiki/Use_case) and "user story"  
(http://en.wikipedia.org/wiki/User_story).  The point is to show by 
example what happens when someone has to interact with the proposed models.

Let me start with a couple of "stories", based on needing to do Ingres 
DBMS work on ingres2006r2 and the same time cross-changes to ingres2006r3.

A. Establish a Piccolo build area based on a label

1. Create an initial Piccolo map file for client!subversion
2. p get client.template
3. Edit client.template to map ingres2006r2
4. p labels and determine what label to use
5. p label -p | p get -l-  (or variation using intermediate files)

   Repeat above five steps for ingres!main and ingres2006r3.

B. Make changes to files in back/dmf/lk and cl/clf/cx (now mapped to 
gl/glf/cx)

1. cd back/dmf/lk ; p open lksample.c ; edit lksample.c
2. cd gl/glf/cx ; p open cxsample.c ; edit cxsample.c
3. jam ; test ; rinse and repeat; run handoffqa
4. p working >working.list | p rcompare -s -lworking.list >working.diff
5. prepare IP and submit; receive approval
6. p reserve -lworking.list
7. p sc -lworking.list
8. cd to main build area and change MAPPATH
9. p ineed -c nnnnnn >ineed.list  # nnnnnn comes from visual output in 
step 7 or Piccolo email
10. p integrate -lineed.list
11. p rcompare -s -lineed.list (to make sure the changes look OK)
12. p sc -lineed.list
13. cd to ingres2006r3 build area and change MAPPATH
14-18. repeat steps 9-13 but with next change number
19. notify IP list of change numbers

I understand the propagate script on Unix makes some steps somewhat 
easier.  Also, SE submits IPs for each separate codeline, but has 
developed some scripts to aid in that process.

Someone needs to carry this story forward as to what happens in each of 
the three models to the changes, as they make their way from ingres!main 
into http://code.ingres.com/ingres/main/src and some tentative Community 
release codeline.  The stories ought to have explicit Piccolo or svn 
paths so that they're not ambiguous.

 From what I understand of the "fresh"/Proposal 1 model, at step 12, the 
Piccolo server will either initiate a 2PC transaction with the svn 
server or queue the change to replicate it to the svn/ingres/main 
branch.  Someone in the "community", possibly an Ingres Corp community 
manager initially, would have to

20. svn merge http://code.ingres.com/ingres/main/src 
http://code.ingres.com/ingres/community1/src
          # community1 being a Community Release codeline
21. svn commit

Individual community contributors could then repeat these steps to apply 
them to their own branches.

C. Make similar changes but as external contributors (a Linux cluster 
implementation!)

1. svn co http://code.ingres.com/ingres/main/src ~/src/ingres
2. cd ~/src/ingres/back/dmf/lk; edit lksample.c
3. cd ~/src/ingres/gl/glf/lk; edit cxsample.c
4. jam ; test ; rinse and repeat ; run <some kind of acceptance test>?
5. prepare some form of submission document and receive approval?
6. svn commit  [open question:  to svn/ingres/main or to some sandbox 
branch]
7. notify approver of submission?

Again, the story has to be carried forward to what happens on the Ingres 
Corp side, in particular, how it gets subsequently integrated into 
ingres2006r3 or other codelines.  It would also be instructive to have 
an example that implements something that doesn't end up being shared, 
e.g., on the community side, some new DMF access method that we don't 
feel comfortable with integrating into commercial codelines but the 
community is eager to have out there for experimentation; on the Ingres 
Corp side, the reintroduction of B1 security, assuming we still want to 
keep that closed source.

Joe