cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <>
Subject Re: Release Criteria
Date Wed, 11 Sep 2013 08:06:09 GMT

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
> 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