> > > 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 ?
IMO, Gerrit can be used to enforce a saner workflow, see previous discussion at [1]. Having a workflow where you are explicitly encouraged to push directly to the repo without review encourages half-baked commits. >From the docs I've read, it seems this might be an Apache policy rather than a CloudStack policy - Apache's new committer doc [2] seems to encourage lack of review: "Rather than creating a patch and submitting it to be actively reviewed and then (hopefully) committed, you can now create a local patch and commit it yourself" In fairness, it does also say "Your patches will still be reviewed by your fellow committers. This will happen after the event", but in the CloudStack case, many people will have lost hours debugging your change by the time (and if) that happens. [1] http://markmail.org/message/inerurmjtc6v57ba [2] http://www.apache.org/dev/new-committers-guide.html#guide-for-new-committers On Wed, Sep 11, 2013 at 5:06 PM, Sebastien Goasguen <run...@gmail.com>wrote: > > On Sep 11, 2013, at 2:57 AM, Wido den Hollander <w...@widodh.nl> wrote: > > > > > > > On 09/11/2013 07:43 AM, Darren Shepherd wrote: > >> On Tue, Sep 10, 2013 at 9:52 PM, Prasanna Santhanam <t...@apache.org> > 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 > >> > >
