[os-infrastructure] RE: [os-engineering] Model discussion boiled down

[Alex Hanshaw]

Just to clarify model b) is a community repository that mirrors a
piccolo branch off of main. In short the models are:

a) head rev main in the community. Bleeding edge, all bug fixes but not
necessarily stable because of development changes.

b) A stable branch from main with no internal development changes and
periodic integration of bug fixes.

 My vote is for option a) for 2 reasons:

 1) Bulk cross integrations quickly become an arduous task.
 2) A lockstep approach between an internal and external repository will
minimize the manual overheads involved in synchronization of internal
and external code repositories. Model b) would be almost identical to an
enterprise release if we lockstep bug fixes on a continuous basis.
 As Andrew points out model a) does not stop massively destabilizing
development projects from being established in an internal (or external)
branch. So model a) does not preclude the changes in approach that
Durwin has put forward.

 Alex

-----Original Message-----
From: opensource-engineering-bounces at lists.ingres.com
[mailto:opensource-engineering-bounces at lists.ingres.com] On Behalf Of
Andrew Ross
Sent: 24 June 2008 21:37
To: Open Source Infrastructure; Open Source Engineering
Subject: [os-engineering] Model discussion boiled down

 
Hi Everyone,
 
Delving into policy, I'd like to deconstruct discussion around our model
for open source affecting server, drivers, and more. Even though
OpenROAD has chosen a stream strategy/model, this may be helpful and
worth considering.

I'd like to share what seems to be crystallization of two (mutually
exclusive) options. This email is a request for comment. 

We intend to bring the outcome of this discussion (expected to be a
finite set of detailed choices) to the executive team to assist in
providing a clear decision.

 
Preamble:
 
We have reached consensus as a team that it is impractical for us to
move off of Piccolo (p) until some outstanding technical and workflow
issues are sorted out. There seems to be agreement that this is the
right direction and recognition that it's going to take time.
 
We also have consensus that p isn't practical for enabling community to
work with us. (it isn't visible to the public, wasn't designed to be,
etc.)
 
Thus we expect to work with p internally and Subversion (svn) for
external code access. This is expected to be the case for the remainder
of 2008. A key next step is deciding how to synchronize the two and what
content to make available publicly.

Policy for server to date has been to use main for development, a branch
off of main for stable enterprise product, and not release source post
GA.



The decision to be made:

The model refers to the relationship between what we share publicly and
when vs. what we protect.

Certified binaries are only provided to enterprise customers. That is
not expected to change.
 
A major decision revolves what content we store in svn and how fresh it
is. If we make the latest code available in svn, will we reduce
inclination of Ingres' customers to pay us for support? This presents us
with two choices of what to store in Subversion:
 
a) The "fresh" model

In this model, the latest and greatest Ingres code is mirrored between
piccolo and svn. Headrev = headrev. Changes to either side are
scrutinized with equal rigor. Changes committed to either side are
immediately propagated to the other system (with locking to avoid
conflicts). While we strive to ensure main always passes basic sanity
testing (builds, can create & start a DBMS,etc.) it is definitely an
unstable/development code base.

Long lived, or particularly disruptive changes are done in branches and
merged back when ready. Inward merges from headrev are done to keep the
code current. Ready implies testing and code inspection has passed as
well as any other process such as DDS document review has been
satisfied. Examples of branches in svn already include: geospatial,
projectD, and more.

Advantages:
- The development team can choose to work in piccolo or svn without
significant differences
- Community can do what development (working on svn) does, on the same
code vintage, with the same tools
- Long lived, innovative, or disruptive projects can work away in
isolation on a branch (allowing inward merges to keep current)
- The same rules for acceptance apply to community or internal work
- The history for each change is built up in svn from this point forward

Disadvantages:
- Is there risk to paying customers?

Commentary:  While in theory customers could run with the community
edition, GPL contamination and instability is a very real concern. I
personally feel no customer would be willing to run their
production/mission critical systems on an unstable/development codeline.


Our tar files we've been releasing contain the same code. If saving on
license fees was that important, I suspect they'd be doing this today.
The opposite is happening... people are interested in Ingres *because*
we're open source. 

As Alex pointed out to me. Issues do not necessarily equate to bugs so
there's value beyond the patches. The way I see it, we're selling
insurance based on an open source asset we own.

Bottom line: Since we can decide to change this model and shut down svn
on a whim, it would be a bad idea for anyone to depend on receiving free
patches via. our community code repository. I personally am not worried
that a fresh svn repository would hurt our business. 



b) The "delayed" model

In this model, the latest and greatest code is stored in piccolo. The
code in svn is purposely out of date. The precise delay would need to be
determined but something over 3 months, possibly up to a year seems to
make sense.

Advantages:
- Clearly, there's a large differentiator between Enterprise support and
community in terms of timeliness of patches being available.
- Community can work, albeit on stale code
- We can still work disruptive features on branches
- The acceptance rules can stay the same for community or internal work
- The history is built up in svn from this point forward

Disadvantages:
- The code is out of date, and would have to be integrated manually
which is much more expensive.
- It isn't practical for development to work from svn... They have no
choice but to work from piccolo
- Try as we may, external committers are 2nd class citizens unless we
give them VPN access. This doesn't scale.


Commentary:

In my opinion, the delayed model doesn't really work for community.
There are some things we could do as they don't depend on current code.
For most things though, it is painful to integrate many changes
developed on stale code.


I am advocating model a. I am interested in what the team thinks, and
whether there's another model we haven't considered.

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