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

Fri Jun 27 04:50:13 PDT 2008

Not exactly.

If the community wants their features in all subsequent releases
they would have to merge the features from the release1 branch to
release2 branch and so on,
wheras if you have a community branch (a trunk for all the community
releases/projects)
the features would be automatically there when creating a new branch.
The same applies to changes/bugfixes for that features - you would have
to
x-integrate them into all follow-up branches, which should have the same
features,
wheras in the other case they would just pulled from the community
branch.

So what is the solution for the community - an own branch where all
their releases/projects
are branched from ("branching is cheap").
But that is exactly what Steve describes in his proposal.

Otherwise I see the whole thing end up in "Ingres Corp. controlled"
branches
- directly branched from the main mirror - and "Community controlled"
branches -
branched from a "community" branch (which was branched from the main
mirror).
I think this will add even more confusion and hazzle to the community.

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 12:59 PM
To: Discussions about the infrastructure needed to support a
trueopensourcecommunity
Cc: Open Source Engineering
Subject: RE: [os-engineering]FW: [os-infrastructure] Re: Model
discussionboileddry(er)

Hi Bodo,

I understand this important difference in philosophy. It comes down to
how strong "gravity" (the propensity to keep content integrating to the
trunk) is. A key principle in open source has always been that forking
code is bad. It's part of open source culture and cited in many research
papers on open source as a source of strength. This is why I feel we
should structure our environment/model to encourage integration.

I understand why people feel allowing the community to diverge is
important. I feel the branches-are-cheap-so-go-for-it philosophy of
proposal 1 accommodates this. For example, in proposal 1, if another
branch was created that Ingres the company does not control or say what
goes in to it, doesn't that satisfy the desire to provide a place where
community can decide on the content? Please see the community release 1
branch in the diagram: http://community.ingres.com/wiki/Community_Model 

Do you agree?

Andrew

-----Original Message-----
From: Bodo Bergmann 
Sent: June 27, 2008 4:11 AM
To: Andrew Ross; 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)

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