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

[Andrew Ross]

Hi Joe,

This looks like the way it works today in piccolo, and has been that way
for a while. Have I misunderstood? If someone made a change to dm2r.c in
r2, and propped it to r3 by way of main (or made the change in main and
patched it to r3), then any feature content or bug fixes affecting
dm2r.c in main will always have to be contended with. 

For clarity, with proposal 1, it is possible to have content in piccolo
(or call it a protected branch in any scs) that is not available to the
public. These changes are not reflected back into main unless explicitly
propped.

In general, I'm reading what you've wrote what do we do when we have to
fork certain files for good reason and how to deal with the complexity
it could cause. (please let me know if I've misunderstood) The proposal
1 model is optimized for keeping the code synchronized rather than
optimizing it for scenarios where it needs to fork. There's an implicit
assumption that the latter is going to happen less often. 

The alternative model (pending the diagram to ensure I understand it
100%) looks like someone would have to manually cherry pick & prop
content to either side to allow community and enterprise to benefit from
each other. This may even have to be a team of people as it's likely no
one person has domain expertise necessary to make the call. 

Andrew 

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Joe Abbate
Sent: June 26, 2008 9:12 PM
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-infrastructure mailing list
opensource-infrastructure at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-infrastructure