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

[Joe Abbate]

Hi Andrew,

Andrew Ross wrote:
> 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.

Yes, that is the way it works today and it's not a major problem because 
"main" is generally a step or two ahead from the current enterprise 
codelines. It *is* possible for somebody to make a change in r2 and then 
manually integrate it into r3. Typically this doesn't happen between 
currently active codelines, but does become necessary say between 
oping20 and ingres2006r2, most likely because a feature was 
significantly changed between 2.0 and 9.1 (clusters come to mind).

Which reminds me of another example: let's say some "community" 
contributor (perhaps with initials AR) decided to re-implement the Linux 
cluster support in a community branch in a significantly different way 
than is currently present in r2/r3/main. For argument sake, let's say 
there wasn't much interest from our commercial customers on a Linux 
cluster solution, but we do have several VMS cluster customers that are 
depending on the current implementation (or the 2.0 implementation). How 
would we handle these divergencies in a single consolidated repository, 
containing both enterprise and community code?

> 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.

That is the latent issue in this entire discussion. I believe those 
preferring a "Fedora model" think Ingres Database Community Edition 
ought to be or is likely to become the "David Database" (Dah-vid, for 
Jacques-Louis David), free to pursue its open source aspirations as seen 
by its contributors. Those preferring otherwise (I don't want to call it 
"fresh" because there can still be an immediately synchronized 
repository pair in the Fedora model), believe the Community and 
Enterprise editions ought to go along more or less at the same pace, 
each including most of the features of the other, with Community perhaps 
taking some riskier stances at first, but eventually being folded back 
into Enterprise. The non-Fedora model also sees Ingres Corp as the 
ultimate arbiter as to what goes into the official Community repository, 
because after all, it is going to be integrated into Enterprise or 
otherwise carry the Ingres brand name. OTOH, the Fedora model requires 
that Ingres Corp place its trust on a somewhat separate entity, even if 
initially we'll be guiding it along.

Joe