deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Lalancette <>
Subject Re: Proposal: add Apache Deltacloud to git scm
Date Mon, 05 Dec 2011 14:07:10 GMT
+1, it makes life much easier :)

Chris Lalancette

On Mon, Dec 5, 2011 at 8:19 AM, Tong Li <> wrote:
> +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