[os-infrastructure] Model discussion boiled down

[Jay Hankinson]

At the moment there probably isn't the need for the extra separation, 
but I suspect there will be a point in the future where we want to 
release new functionality in a stable community release but not pull it 
into the enterprise code line. If there is only 1 main branch this 
_could_ cause problems . I really only raise it as a suggestion we may 
decide that it's not worth worrying about.

J

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