deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Lalancette <clalance...@gmail.com>
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 <litong01@us.ibm.com> wrote:
> +1, After using git for about 5 months, I like it more than others.
>
> Tong Li
> Emerging Technologies & Standards
> Building 501/B205
> litong01@us.ibm.com
>
> David Lutterkort <lutter@redhat.com> wrote on 12/02/2011 07:57:17 PM:
>
>> From: David Lutterkort <lutter@redhat.com>
>> To: infrastructure@apache.org
>> Cc: dev@deltacloud.apache.org
>> 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 <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.
>>
>>
>

Mime
View raw message