[O/T git and workflows] A couple of questions
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?
on Tue Mar 06 2012, Brian Schrom <brian.schrom-AT-pnnl.gov> wrote:
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.
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.
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.
Or, you fork the repo on GitHub, push your work to your fork, and submit a pull request to the maintainer.
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>
Did you read http://news.gmane.org/find-root.php?message_id=%3cm2ipiqu3nj.fsf%40pluto.lua... ?
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
Dave Abrahams wrote:
Come to speak of it, there is one aspect of the git-flow tool that annoys me nearly every day. It enforces full merges. So if I want to do a fast-forward merge after a rebase, I have to run four commands: $ git flow feature rebase $ git checkout develop # alias $ git cd $ git merge feature/featurename $ git branch -d feature/featurename instead of just the regular single git-flow command: $ git flow feature finish -r featurename # alias $ git fffr featurename The latter would work too, but it leaves a visible separate branch and merge in history which is exactly what I was trying to avoid by doing a rebase before merging. While writing this, I've decided I'll file a ticket on this to the git-flow team. If anyone can think of a way to make fast-forward merge on rebase less kludgy in the meanwhile, I'd be glad to hear about it. -Julian
On Wed, Mar 14, 2012 at 5:54 PM, Dave Abrahams <dave@boostpro.com> wrote:
In my world there's no one central boost repo. There's an "official" repo for each individual project in Boost.
I have a worldview that goes like this: There's an "official" repo for each individual project in Boost. There is also a central boost repo, but it contains only the relatively few infrastructure files that apply to Boost as a whole, plus "references" to the official repos for the individual projects. The exact form of the "references" is immaterial to this world view, although certainly critical to the mechanics of how the central repo is used. Is that just a slightly more detailed version of your worldview, or do you literally mean "no one central boost repo"? If you literally mean that, I'm lost. How would any person or process know what's a part of Boost? --Beman
2012/3/15 Beman Dawes <bdawes@acm.org>:
They may get this information either from the Boost website or from the organization view on github (https://github.com/boost-lib). We may provide a tool that downloads all projects from this organization and sets up the required infrastructure. There is no need to keep this infrastructure in an additional repository. cheers, Daniel
on Thu Mar 15 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
I literally mean that, at least in the way I've been thinking of "one central boost repo."
If you literally mean that, I'm lost. How would any person or process know what's a part of Boost?
Certainly, we'll have to maintain a list of "references" delineating what's a part of Boost (e.g. like https://github.com/boost-lib/boost/tree/master/libs or http://gfxmonk.net/dist/0install/index/), and that list should be under source control somewhere, so you could think of that as central. However, there's not necessarily any reason that list must be in the same repo as any of those few infrastructure files that apply to Boost as a whole, or that those files should necessarily be grouped together (i.e. we should feel free to determine the most appropriate repository boundaries), or that any user of Boost will need a working copy of the repository that maintains the list of references. You might well also think of the top-level Boost website material as "central," but that maybe ought not to go in the same repo as the list of references (or maybe not in any VCS repo–a database-backed CMS like Wordpress might be better). The point is, Boost itself may have several "central" repositories separate from those of its constituent libraries, but there's no reason there has to be just one. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Mar 15, 2012 at 10:44 PM, Dave Abrahams <dave@boostpro.com> wrote:
Yes, that's what I think of as the central repo. I.E. the root of the tree. Even if the only thing in it is a simple text file listing the URL's of the next level down repos, it still needs to be in a repo. At some point we might have several possibly overlapping trees, but there isn't any current plan to do so.
Important points. Understood.
Ah! I see your point. Boost as an organization will have a number of repositories, wikis, databases, mailing lists, etc. In an organizational sense they are all part of Boost, but it doesn't really make a lot of sense to describe any single one of them as "central". --Beman
participants (5)
-
Beman Dawes -
Brian Schrom -
Daniel Pfeifer -
Dave Abrahams -
Julian Gonggrijp