Subject: Re: [boost] [O/T git and workflows] A couple of questions
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-03-14 17:54:39
on Tue Mar 06 2012, Brian Schrom <brian.schrom-AT-pnnl.gov> wrote:
> This is slightly off topic, but with recent (and future ;) ) Git
> discussions, hopefully not too off topic...
> If Boost were to adopt Git, I believe Gitolite
> http://sitaramc.github.com/gitolite/ -- docs) or something similar would
> need to be used which provides some centralization features. Maybe github?
We use gitolite for BoostPro's private repositories. It's great if you
have to manage private repos and you can't entrust the storage to a
service like BitBucket (https://bitbucket.org/). But Boost doesn't need
private repos, so I think we'll use GitHub. It seems to be a winning
technology. The only real competition out there is BitBucket, which now
gives away unlimited private repository storage for free but AFAICT is not
winning the popularity contest.
> Gerrit (http://code.google.com/p/gerrit/) is primarily a code review
> tool, though provides some centralized support.
I don't know what you mean by "centralized support" in this case.
> git flow (https://github.com/nvie/gitflow) has some nice wrappers
> for branch management. This looks especially appealing for gently
> introducing people to git. It provides structure and reduces the number
> of commands.
I don't know about that last part ;-). Every additional tool adds more
commands, and it's not as though the raw git commands go away or even
become obsolete. But I like git-flow.
> My question is what the workflow, tools, and experience people have with
> combining all of these tools. I think this community will need
> something along these lines if it is to transition to Git anyway, so
> maybe this will get that part of the discussion started.
> Just to keep the discussion on git going...
> In my "brain storming" world, there is the central boost repo (which
> currently exists), I clone it. (When can we start submitting to github?
> :) )
In my world there's no one central boost repo. There's an "official"
repo for each individual project in Boost.
> I use git flow locally for my own branch management. This allows me to
> work on multiple features independently.
Yeah, you might consider topgit while you're at it.
> When a feature is completed locally, I send the patch (possibly via
> gerrit ) and that patch sits in the maintainers review queue. If
> accepted, the patch is applied and merged for the next release.
Or, you fork the repo on GitHub, push your work to your fork, and submit
a pull request to the maintainer.
> Largely, I believe this is what exists right now. Admittedly, I've only
> ever submitted one patch to Boost. That was an email directly to the
> library author.
> What I want to understand is, if such tools were adopted, would it lower
> the burden on library maintainers enough to justify the change?
It would, IMO.
> Again, my perception of the way things currently are vs could be with git:
<snip - I have nothing to add to this part>
> * Where would build-bot/Jenkins interact in this process? It seems
> that there are a few places...1) Want to be able to test local branch
> during development, 2) then test during the patch review and approve
> process, and 3) finally test on the integrated branch.
Did you read
> * Would the "better" localized development tools (git + git flow + more
> direct patch submission) facilitate more participation in the community
> over the current method? (my guess is not much, though the people that
> do contribute might appreciate the improvements. And some would
> consider them not improvements and stop contributing?
Doubtless it would be a turn-off for some, but I think it'd be a win
> * Would the review process save the maintainer's enough time and effort
> that they're more able to process more patches on a regular basis?
I personally find that reviewing GitHub pull requests is fast and easy.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk