On 01/09/11 12:17 +0200, Tomas Sedovic wrote:
On 09/01/2011 10:58 AM, 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.
>
> Take care,
> --Hugh (now returning to vacation)
>
At this point I don't really mind our current process, but I understand
that it may be daunting for the newcomers, and I do like the proposals
in the article.
The gist of the proposal is to have a canonical branch (master) that you
can always pull from and deploy from. New features happen on topic
branches forked off of master.
Topic branches exist locally and get pushed to the central repo at will
under the same name so others can see them and hack on them.
Once a task is done, the author issues a pull request and someone will
pull their branch and test it. If that's okay, it'll get ACKed and
merged into the master branch (hopefully) without ever breaking things.
A lot of this we do (or strive to do) already.
We try not to bring tests and functionality on master because everybody
bases their work on it.
Some things like the migrating to Rails 3 or now killing Condor off
are/were happening on separate branches.
Adopting the proposal would merely formalize that.
The main difference I see is in the tooling. What they do with GitHub
and pull requests we do with mailing list and git-am.
The process (write code, publish it, have someone look it through and
push to master if ACKed) isn't changed.
I agree that mailing lists and patches may not be the most user-friendly
way to handle this and the fact that we were looking for a patch
management system in the past seems to reinforce that notion.
The GitHub tools seem to do all I would need (it's public, you can see
open review requests and you can have discussion around the code).
On top of that, GitHub is pretty standard for Ruby/Rails projects and a
lot of our potential contributors would be familiar with that. Plus,
every Aeolus project except for Conductor and Configure is there already.
Was there a planned reason for having conductor and configure not
hosted on github? I'm a new guy on the project so I don't have all
the history here. If those two projects have to stay on fedorahosted,
perhaps we could clone the repos out to github to make the workflow
consistent.
Possible caveats:
* We should have the repos replicated somewhere so that we're not
blocked when github goes down. I think having a fedorahosted mirror
would solve that.
I like this idea a lot, clone each of the projects out there and
automate the update.
* Github is proprietary and people may have issues with that. Since git
itself is open, I don't think we're risking much in terms of a lock-in.
If it works better than the Free alternatives, it's okay with me.
* The process described in the article revolves around a project has a
single public instance. We will want to have our projects deployed on as
many machines as possible. There may be some impedance mismatch adapting
their workflow to Aeolus. Though I don't see any now.
On the plus side, it would stop flooding this mailing list with patches,
which some folks had trouble with in the past.
I'm all for it.
--
No trees were killed to send this message, but a large number of
electrons were terribly inconvenienced.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel