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

[Alex Hanshaw]

Chris

 When SE integrate any change into main from any release they face the
possibility of having to port the change based on code divergence. Worse
still some changes will cross clean but work in the same way at
run-time. This is not a problem introduced by only mirroring main and
having community branches off of the community-main mirror.
 If you mirror a branch off of main like ingres2006r2 some changes will
still need to go to main. Internal staff will have to do the integration
and face the same merge issues because of code divergence.

 Alex

-----Original Message-----
From: opensource-engineering-bounces at lists.ingres.com
[mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
Joe Abbate
Sent: 27 June 2008 02:12
To: Chris M. Clark
Cc: Open Source Engineering; Discussions about the infrastructure needed
to support a true open sourcecommunity
Subject: Re: [os-engineering]FW: [os-infrastructure] Re: Model
discussionboiled dry(er)

Hi Chris,

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.

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?

Joe
_______________________________________________
opensource-engineering mailing list
opensource-engineering at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-engineering