Mailing-List: contact dev-help@deltacloud.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@deltacloud.apache.org
Received-SPF: pass (nike.apache.org: domain of ferncam1@gmail.com designates
 74.125.82.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1322873837.20225.52.camel@avon.watzmann.net>
References: <1322873837.20225.52.camel@avon.watzmann.net>
Date: Sat, 3 Dec 2011 13:30:05 -0500
Message-ID: 
 <CAARMrHWz76dkKNWJvH_LW2hMPBjSu55mRV7yMTt3KOm6aOo8Qg@mail.gmail.com>
Subject: Re: Proposal: add Apache Deltacloud to git scm
From: Adrian Cole <ferncam1@gmail.com>
To: dev@deltacloud.apache.org
Cc: infrastructure@apache.org
Content-Type: multipart/alternative; boundary=f46d044402d04e98e504b33446f3

--f46d044402d04e98e504b33446f3
Content-Type: text/plain; charset=ISO-8859-1

+1 good luck!  I hope deltacloud is allowed to use git.

-A
On Dec 2, 2011 7:57 PM, "David Lutterkort" <lutter@redhat.com> wrote:

> 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 <cutting@apache.org> 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 people.apache.org 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.
>
>
>

--f46d044402d04e98e504b33446f3--