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

[Chris Clark]

On 6/26/2008 6:12 PM, Joe Abbate wrote:
> Chris Clark wrote:
>> Coming back to the hypothetical DMF change, this should be done in a 
>> public experimental branch, the issue would be if this experiment is 
>> considered a success and if we cross/merge/integrate it into "Main 
>> Community Mirror". This would then end up in main and future 
>> Enterprise Branches, I don't think it would be integrated into 
>> existing commercial branches (they are supposed to be feature 
>> complete, support should only be integrating bug fixes into existing 
>> commercial branches).
>
> But what I think that the proponents of the "fresh", single 
> ingres!main/svn:main fail to realize is that say the new access method 
> (NAM) adds a new file, back/dmf/dmp/dm1nam.c and adds calls to the new 
> functions in back/dmf/dmp/dm2r.c.  With the immediate, unbuffered 
> approach, those changes would presumably move from the experimental 
> branch to svn:main and immediately update Piccolo's ingres!main.  No 
> problem yet.  Now someone makes a fix to dm2r.c in ingres!ingres2006r2 
> and needs to propagate it to ingres!ingres2006r3.  If it overlaps the 
> NAM calls, he/she is forced to work around the NAM changes when 
> integrating the fix into ingres!main and then ensure he/she doesn't 
> propagate any of the NAM changes into ingres2006r3.  With the 
> "controlled", "buffered" approach the fix can flow from 2006r2 to main 
> to 2006r3 as usual because main doesn't have the NAM changes.

You've convinced me we need the detail use cases sooner/now :-) I think 
we need the high level/low detail ones too. This is a great example.

I'm still not in favor of "fresh" (I want a buffer!) But I think the 
above scenario is just like we have today, we replace "svn experimental 
branch" with "piccolo, ingres2006r4" the inconvenience would still be 
there for going from 2006r2->main->2006r3. If something is moved into 
main, the idea is that we want it, moving forward, in later code lines 
for ones where we do not want it we have to "p ignore" where we can and 
manually integrate when we can't. I don't think this is a an objection 
to the fresh approach (I may have missed a fine point on this but it 
looks the same to me).


> The same applies in the other direction.  Just do a p describe -sfiles 
> 469243 to see the number of files that had B1 code in them.  If we add 
> them back into ingres!main, in the immediate, unbuffered model, the 
> files would be publicly available at 
> http://code.ingres.com/ingres/main/src/.  Even if the latter is made 
> into a private repository, how does a subsequent ingres2006r2 change 
> to adtcompute.c get propagated to the public community codeline?

I agree 100% with this one. This is the thing that that perturbs me 
most, anything non-open source has to enter piccolo ingres!main (or we 
can't get it into any other piccolo code line). Being egocentric for a 
second, from my perspective we have this; 
http://bugs.ingres.com/browser/main/src/front/st/crsfiles/oracle.crs 
there isn't anything really wrong with this being visible (totally 
benign) but it doesn't add any value to the community (you can't use 
it), with Proposal 1, this is needed as we can't filter any lower than 
the directory level. There may be non benign ones (your B1 example is 
again excellent). Having a private to Ingres buffer branch (somewhere, 
either in piccolo or svn) helps with this, but this is probably going to 
be a manual process.

Chris