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

[Bodo Bergmann]

Andrew,

you wrote:
"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."

If you start from this assumption I understand why you are fighting for
it.
This might be true for bug fixes.

But in a vibrant community I see it rather the opposite way:
There will be many changes to existing fetures and a lot of new features
(the Development Sprint in London just showed this).
The community will decide what's going to be the community release.
Example:
If the community decides to change some code which would tremendously
improve
the performance of the community version (doesn't matter if it's Ingres
or OpenROAD or whatever),
but which would e.g. rip off backward compatibility for the enterprise
version
or violate B1 security, then with proposal 2 (or 3 - made by Steve),
this would be possible wheras with proposal 1 it would have to be
rejected by Ingres Corp.
with the argument "It brings problems for our enterprise version".
Steve mentioned "Project D" as another example.
Such rejections will add a "nice" subtitle to our Open Source community
commitment statement:
"as long at it serves us".

I want the community to decide for itself what they need,
we don't have to be the wise guys who tell the community what's best for
them (and us).
That doesn't mean we are off the field. We will still support the
community,
guide, teach & help them, let them know about the implications of the
changes, etc.
But in the end there will be some kind of community committee which will
have the say.
A vibrant community will serve us better and eventually come up with
more innovative solutions than one
which is permanently dominated and patronized by Ingres Corp.

That's why 
Bodo.

-----Original Message-----
From: opensource-engineering-bounces at lists.ingres.com
[mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: Friday, June 27, 2008 3:50 AM
To: Discussions about the infrastructure needed to support a true
opensourcecommunity
Cc: Open Source Engineering
Subject: RE: [os-engineering]FW: [os-infrastructure] Re: Model
discussionboileddry(er)

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
_______________________________________________
opensource-engineering mailing list
opensource-engineering at lists.ingres.com
http://lists.ingres.com/mailman/listinfo/opensource-engineering