On 09/01/2011 03:59 PM, Matt Wagner wrote:
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.
This is a great point. We definitely should be doing this regardless of
where our primary repo is hosted.
> * 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!
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
--
No trees were killed to send this message, but a large number of
electrons were terribly inconvenienced.