On 01/09/11 10:23 -0400, Chris Lalancette wrote:
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.
Completely agree with you that it's important for anyone that has skin
in the game to have visibility into the changes associated with a pull
request. I've done pull requests with github in the past, but haven't
sent them to an 'organization' on github. I haven't figured out
whether or not everyone in the github organization is notified of the
pull request. If they are, this lends itself well to providing the
breadth of visibility (assuming we add all the developers to the
aeolus organziation on github).
As a really, really, really new-comer to the project I will say the
post patch ACK process is very straight forward. What isn't so
straight forward is that we're using one mailing list and I have
absolutely no idea who it is I'm waiting for an ACK from, when to
expect it, and who will merge the patch after the discussion is
complete. Some patches I care about, some I don't and it would be
nice to have a bit of issolation between the project patch sets. All
that said, we've been using the same process for number of other
projects here, so it's not like it's insurmountable.
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.
Feature branches have been very useful for other projects I've
been working on. Rather than having one bleeding edge branch to take
all the latest and greatest features, feature branches provide a
couple benefits over one "next" branch. For instance, if there are
multiple commiters that need to collaborate on a feature that isn't
ready to introduce to the larger audience, or if the patch set is
under development for a longer period of time git allows you to do
continual rebasing, and patch sets that are related can be set aside
if needed then come back to them later, without having to rebase
interactive and put everything back together in order.
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.
I agree it's OK too. That said, with the projects out on github already,
why not take advantage of the features integrated with the tool rather
than just using it for a hosted git repo. Oh, something else I found
interesting for those that aren't interested in command line based git
pull requests:
https://github.com/schacon/git-pulls.git
http://thechangelog.com/post/2878756980/git-pulls-command-line-tool-for-g...
--
Chris Lalancette
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
Thanks,
Chris