[os-infrastructure] Model discussion boiled down

[Alex Hanshaw]

Hi J

 I don't think you need the main duplicate branch in piccolo. You add a
level of additional cross integrations.
 As Andrew pointed out community branches from svn-main can be created
for changes that we do not want in the enterprise release until such
point as they are considered stable enough to integrate from their own
community branch into the scv-main for synchronization into piccolo's
main.
 The geo spatial project is already doing this. Why mirror a mirror?

 Alex

 

-----Original Message-----
From: opensource-infrastructure-bounces at lists.ingres.com
[mailto:opensource-infrastructure-bounces at lists.ingres.com] On Behalf Of
Jay Hankinson
Sent: 25 June 2008 09:19
To: Discussions about the infrastructure needed to support a true open
sourcecommunity
Cc: Open Source Engineering
Subject: Re: [os-infrastructure] Model discussion boiled down

I would also advocate option a. It's my feeling that enterprise 
customers aren't really paying to get just patches. They're paying to 
know that when something goes wrong (or when they just need advice), 
there's someone at the other end of the phone that will help them out. 
Downloading the current fixes is fine as long as someone else has 
reported your problem. Redhad have fully embraced this model (CentOS is 
a re-badged version of the RHEL code) and it seems to be working for
them.
However, I might suggest an extra level of indirection when synching 
between piccolo and the community VCS. Main in piccolo would become main

for the enterprise product line. We then branch this in piccolo to 
create a "community main" which can be kept in sync with what ever is in

the public repository. The community side of things can then move ahead 
a fast as it needs to without fear of destabilizing the enterprise 
product and without potential rendering parts of the main-line code 
different enough to make propagating changes from the existing release 
codeline into main.
The community main would essentially be come the gatekeeper for all 
community changes which would only be pulled into enterprise after 
completing a more stringent verification and demand evaluation process.
I personally like the model Open Road has adopted where ALL new 
development is done in the OS branches and stuff is the pulled into 
enterprise as it becomes ready. (That's my recollection of how it was 
explained anyway, please correct me if I'm miss remembering).

J
Andrew Ross wrote:
>  
> 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-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
>   

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