deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <>
Subject Proposal: add Apache Deltacloud to git scm
Date Sat, 03 Dec 2011 00:57:17 GMT
Hi all,

I would like to ask to have Apache Deltacloud added to the experimental
git setup.

Deltacloud has been at the ASF since May 2010, and graduated from the
incubator in October. When the project was started in the summer of
2009, it was on git, and only moved to svn when entering incubation.

Even though, we are still a very git-leaning project: committers
generally use git-svn to commit, the workflow is very much git centric
(it relies heavily on mailing patches around and trying them out on
lcoal branches for review)

We'd be very excited to be able to switch back to git, and forget all
about git svn dcommit ;)

I'll attach an email I wrote to board@ a while ago that details our
experience with git and git-svn; as part of the git experiment, we'd be
very interested in helping shape the git tools at ASF, help formulate
processes etc.


Here goes the long email I wrote the other day:

On Wed, 2011-11-16 at 21:58 -0500, Greg Stein wrote:
> On Wed, Nov 16, 2011 at 11:48, Doug Cutting <> wrote:
> > On 11/15/2011 11:44 AM, Bertrand Delacretaz wrote:

> We have a responsibility to provide our communities with "best
> practices". We have generally couched that as "The Apache Way".

I'd argue that we won't be able to develop best practices until git is
used widely enough. In addition, there are plenty of projects that use
git and have one official, canonical repo. Granted they don't always
apply the same legal rigor to their process as the ASF, but there's
plenty to learn from them.

> I want to see metrics from CouchDB.

I'll share some of the experiences that Deltacloud had; since the
project started on git, and switched to svn only because of entering the
ASF incubator, the project's workflows and conventions are about as
close as you can get to a git-only project while using git-svn.

>  Has community involvement been maintained?

Yes, we've added a few new committers during incubation, and have
generally not had any problems because of the git-centric nature of the

> What are the push rates?

Varies ;) The workflow that Deltacloud (and a lot of git-centric
projects) use is review-before-commit, i.e. you post your proposed
patches on the mailing list, and should only commit them to the central
repo (now done via 'git svn dcommit') once at least one other person has
reviewed and ACK'd them.

Patches from non-committers are committed by a committer on the
non-committer's behalf. Unfortunately, svn does not preserve the
separate Author and Committer roles that git does; we've therefore
switched to using 'Signed-off-by' to make sure we record the original
author of a patch. Of course, committers are responsible for checking
that patches they commit for others are backed by a CLA etc.

>  How are people sharing changes?

Mostly on the mailing list, sending patches around (for those who
haven't used git a lot: git makes it very easy to work with patch series
from others, in parallel to your own ongoing work) I personally find
github's model of sending merge requests and merging in other repos less
productive, in particular since I am very strict about maintaining a
linear master branch (git-svn forces that, but even for my non-ASF
projects do I insist on that, since it makes things like bisecting a ton

On occasion, I've uploaded a patch series to my page,
usually when the patches are huge and there is danger that they get
mangled in email.

In other projects, I've merged patches directly from other people's
repos, but as I said, I find that more annoying than applying a series
of patches directly.

> Branches in the ASF repository, or are people hosting them elsewhere?

For Deltacloud, we do not have any public branches. I think there were
one or two occasions in the pre-incubator days where we had a public
branch because we did a fundamental overhaul of the codebase and didn't
want to disturb the ongoing work on the master branch.

Whether you see a lot of public branches in a git project depends a lot
on how the project takes in contributions: via merge from other git
repos, or through patches posted to a mailing list. But even when
contributions come through merging of other git repos, you rarely see
branches in the canonical git repo.

There, you'd expect to see branches for exactly the same reasons you'd
see them in svn: to support longer-lived work that deviates from master.

> How does that affect the community? 

It highly depends who the community members are: if they have a strong
git background, they'll be unhappy with svn; if they have a strong svn
background, they'll be unhappy with git. And not just the tools, but
also the differing workflows these tools accomodate.

> Do we need further tooling, such as what you find at Github?

IMHO, a gitweb instance would be good enough for Deltacloud; a gitorious
instance of course much shinier. Whatever infra feels is the best tool
from their side would be fine by me.

> Do we have a standard
> recipe for moving a subdirectory from one project to another once that
> subdir becomes a subproject and then a TLP?

Is the plan to have one giant git repo for all of ASF ? That feels very
unnatural in the git world, a setup of one repo per project (or even
multiple repos per project for larger projects) is much more natural.
For example, for Deltacloud, in an ideal world, we'd have one repo for
the server, one for each client, and one for the website.

Just as one datapoint: Fedora moved from a giant CVS repo for all Fedora
packages to a git infrastructure a while ago. In the new infrastructure,
each package is its own repo, i.e. there are now thousands of git repos
for the Fedora distribution.

> Do we need ALL these questions answered before approving Git for
> general use? Of course not. But we need something, and I would say a
> majority of those answers. We can't go from zero years of experience
> to a sudden assumption that the Apache Way is still being followed by
> all our projects, regardless of their tool choice.

As an organization, the ASF might have zero years of experience with
git, but I suspect there is a large body of experience within the
membership from their work outside of ASF.

View raw message