Re: [boost] [O/T git and workflows] A couple of questions

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
> (https://github.com/sitaramc/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
http://news.gmane.org/find-root.php?message_id=%3cm2ipiqu3nj.fsf%40pluto.luannocracy.com%3e
?

>  * 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
overall.

>  * 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