On Thu, Sep 01, 2011 at 12:17:59PM +0200, Tomas Sedovic wrote:
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.
As someone who was until recently a "newcomer," I didn't find the
process that daunting. And while we absolutely need to be welcoming to
newcomers, I don't think "easy for new people to learn" should be the
primary feature of our entire workflow.
That said, I'm still in favor of switching. I've used GitHub on non-work
projects here and there, and have grown fond of it. But for me it's that
I find GitHub slightly easier to use and slightly, well, shinier than
what we have now. I'm not sure that's a compelling reason to switch.
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.
Pushing WIP branches to the central repo doesn't happen that often on
our project, but wouldn't be a bad habit to get into IMHO, GitHub or
not.
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.
As a relative GitHub n00b, I did this just the other day to send Justin
a patch for aeolus-website. This was astonishingly easy.
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 agree, but I'd make the counter-point that if we don't move to GitHub,
the same applies -- we should have the existing FedoraHosted repo
replicated somewhere so we don't block when they go down. That's
happened to us before.
* 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.
I'm not too bothered that the source code to GitHub is proprietary.
Sure, I wish it wasn't, but it wouldn't keep me up at nights.
What *does* concern me a little is that I'm not sure some of the things
they implement would be transferable if we left GitHub. For example,
the code reviews:
https://github.com/features/projects/codereview
* 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.
Very tangential, but I find the fact that GitHub pushes changes live
to their site several times a day to be intriguing. It's so against the
grain of what most companies do, and yet it makes a lot of sense.
On the plus side, it would stop flooding this mailing list with
patches,
which some folks had trouble with in the past.
I would be all for that!