deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Fojtik <mfoj...@redhat.com>
Subject Re: Proposal: add Apache Deltacloud to git scm
Date Mon, 05 Dec 2011 10:44:48 GMT
On Dec 3, 2011, at 1:57 AM, David Lutterkort wrote:

=+ 1 :)

> 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.
> 
> 

------------------------------------------------------
Michal Fojtik, mfojtik@redhat.com
Deltacloud API: http://deltacloud.org


Mime
View raw message