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

Subject: [boost] [O/T git and workflows] A couple of questions
From: Brian Schrom (brian.schrom_at_[hidden])
Date: 2012-03-06 12:19:34

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?

Gerrit  (http://code.google.com/p/gerrit/) is  primarily  a code  review
tool, though provides some centralized support.

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.

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?
:) )
I use git flow locally for my  own branch management.  This allows me to
work on multiple features independently.
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.
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?
Again, my perception of the way things currently are vs could be with git:
centralized subversion server.                    centralized git server
(gitolite?)
svn checkout trunk                                git clone developer
Use whatever local strategy for development       use git flow +
whatever local strategy for development
create patch and attach to TRAC ticket            git push to gerrit
server (for instance)
poke people on mailing list about patches         (poke people on
mailing list about pending reviews and such)
maintainer applies patch and pushes to server     An approved patch gets
pushed to centralized server.
 * 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.
 * 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?
 * 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?