cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: Release Criteria
Date Wed, 11 Sep 2013 13:57:37 GMT
Well in the apache model committers are nominated.  So basically we should trust our committers.
 So I'm going to say we enforce this by having good discipline.  In really not a fan of adding
more process.  In communities where gerrit is used its usually done in a model where anybody
can commit, so you're forced to have a rigid process.  We should take nominating committers
seriously and committers should know best.  

Frankly, for how young ACS is, I'm surprised at the number of committers.  I always hate when
people gauge the strength of a community by the number of committers.  Cause everybody knows
the way to get things done more efficiently is to add more opinions...


On Sep 11, 2013, at 1:06 AM, Sebastien Goasguen <> wrote:

> On Sep 11, 2013, at 2:57 AM, Wido den Hollander <> wrote:
>> On 09/11/2013 07:43 AM, Darren Shepherd wrote:
>>> On Tue, Sep 10, 2013 at 9:52 PM, Prasanna Santhanam <> wrote:
>>>> I think we messed up with the users again this time. Partly a fault
>>>> that we can't get beta-quality builds for users to test. Seeing
>>>> everyone run 4.2 packages after release announcement and reporting
>>>> critical bugs I wish could've happened soon after freeze and during
>>>> the test schedule.
>>>> To get beta quality builds we need to absolutely treat the master
>>>> branch as 'stable'. Never hurt it, automate against it, branch off
>>>> quality builds from it and create packages and mirror them. That'll
>>>> save us a ton of effort.
>>> Just to reinforce that branching point.  For all practical purposes, master
>>> should be treated like a release branch.  You only commit to master AFTER
>>> you've done QA.  Builds from master should be tested for only
>>> re-verification (or run your automated regression tests, since you
>>> obviously created those when you did QA) and for integration testing.
>>> So, I have no clue how people are doing QA, but if your checking into
>>> master when you think you're "dev done," so that QA can pickup a build and
>>> start testing, then your doing it all wrong.  Check into branch, test from
>>> branch, when all is swell, merge to master, revalidate on master.
>> I think that's a good point. Master is not a playground. Stuff which goes in there
should work.
>> A broken master also slows down other devs. I can't remember the number of times
I've been debugging master for hours to find out something broke it.
> so how do we enforce this ?
>> Wido
>>> Darren

View raw message