[os-infrastructure] Model discussion boiled down
Jay Hankinson
jeremy.hankinson at ingres.com
Wed Jun 25 03:50:20 PDT 2008
Sorry, I meant to say enterprise releases in my last sentence ;-)
Jay Hankinson wrote:
> 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
>>
>
> _______________________________________________
> opensource-infrastructure mailing list
> opensource-infrastructure at lists.ingres.com
> http://lists.ingres.com/mailman/listinfo/opensource-infrastructure
More information about the opensource-infrastructure
mailing list