On 09/11/2013 10:06 AM, Sebastien Goasguen 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 ?
Good question, but I think eduction is one of them.
It's just like having good commit message and having your Author en
E-Mail set up properly in Git.
Wido
Darren
