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... Darren On Sep 11, 2013, at 1:06 AM, 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 >
