deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tong Li <>
Subject Re: Proposal: add Apache Deltacloud to git scm
Date Mon, 05 Dec 2011 13:19:28 GMT
+1, After using git for about 5 months, I like it more than others.

Tong Li
Emerging Technologies & Standards
Building 501/B205

David Lutterkort <> wrote on 12/02/2011 07:57:17 PM:

> From: David Lutterkort <>
> To:
> Cc:
> Date: 12/02/2011 07:58 PM
> Subject: Proposal: add Apache Deltacloud to git scm
> 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.
> David
> 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
> project.
> > 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
> easier)
> 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