On 09/01/11 - 04:58:17AM, Hugh Brock wrote:
Hello Aeolus folks.
I've had a number of complaints, or at least expressions of surprise,
recently from Aeolus newcomers about the process we use to post,
review, ACK, and push code to the master repo. Seems we are if not
behind the times at least hidebound, in the eyes of e.g. your typical
github guy.
In general I feel our process has served us well over the last couple
of releases -- in particular, I mandated the
"end-to-end-test-before-ack" policy a while back because we were
getting a high level of "this could never possibly have worked" type
of bugs in the master tree.
However I wonder if we couldn't move faster with some improvements to
the process. Simon Harris sent me
http://scottchacon.com/2011/08/31/github-flow.html this morning as an
example of how things might develop.
If any of you have felt restrained by an excess of process in the
project in the past, I'd appreciate you taking the time now to read
the above and propose changes to what we do. Thanks in advance.
As the old-timer around here, I will say that I do like the post patch and
ACK process. It is familiar in the open-source world, it is easy to go to one
place to see all of the proposed patches, and I think it keeps code quality up.
What I'm most worried about with the github model is pull requests that go in
without everyone being able to see them.
As has been pointed out elsewhere in the thread, the model expounded upon in
the above link is somewhat a description of our process, though it is slightly
different. Actually, what is really interesting is that it basically describes
our process when we had the master/next split; the master branch was always
"deployable", but it turned out that it had exactly zero consumers. I
don't
think anyone wants to go back to that.
For me, I think the current process for patches is OK. There are other areas
that I would concentrate on making simplification before changing the patch
process yet again.
--
Chris Lalancette