[os-infrastructure] Model discussion boiled down

Wed Jun 25 03:48:58 PDT 2008

The svn branches are for development but we will want to release 
features in stable community releases at some point. This will mean 
folding the branches in to svn-main, in much the same way we do for 
community releases
Alex Hanshaw wrote:
> That's what svn branches are for. See geospatial. If we want to pull
> stuff back into the enterprise product then the changes are merged from
> the svn branch to svn-main where there are synchronized with piccolo
> main.
>
>  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 11:12
> To: Discussions about the infrastructure needed to support a true open
> sourcecommunity
> Cc: Open Source Engineering
> Subject: Re: [os-infrastructure] Model discussion boiled down
>
> 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
>>   
>>     
>
> _______________________________________________
> 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
>