Proposal: add Apache Deltacloud to git scm

[David Lutterkort <lu...@redhat.com>]

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

Re: Proposal: add Apache Deltacloud to git scm

[Adrian Cole <fe...@gmail.com>]

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

-A
On Dec 2, 2011 7:57 PM, "David Lutterkort" <lu...@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 <cu...@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.
>
>
>

Re: Proposal: add Apache Deltacloud to git scm

[Sang-Min Park <sa...@eucalyptus.com>]

David,
This is a great proposal!

Sang-min

On Fri, Dec 2, 2011 at 4:57 PM, David Lutterkort <lu...@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 <cu...@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.
>
>
>


-- 
*_________________________*



*Sang-Min Park - *Software Engineer

*Eucalyptus Systems*

www.eucalyptus.com

+1 434 825-4939



Follow us on Twitter <http://twitter.com/#!/eucalyptuscloud>

Like our Facebook
Page<http://www.facebook.com/pages/Eucalyptus-Systems-Inc/164828240204708>

Keep up-to-date with
us<http://go.eucalyptus.com/Sign-Up-for-Cloud-Computing-News.html?Offer=Other&OfferDetails=Sign%20Up%20for%20Cloud%20Computing%20News&LeadSourceDetails=Eucalyptus%20Website&OfferURL=http%3A%2F%2Fgo.eucalyptus.com%2FSign-Up-for-Cloud-Computing-News.html>

*_________________________*

Re: Proposal: add Apache Deltacloud to git scm

[Francesco Vollero <ra...@gmail.com>]

+1 on that idea
On Dec 3, 2011 1:57 AM, "David Lutterkort" <lu...@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 <cu...@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.
>
>
>

Re: Proposal: add Apache Deltacloud to git scm

[Chris Lalancette <cl...@gmail.com>]

+1, it makes life much easier :)

Chris Lalancette

On Mon, Dec 5, 2011 at 8:19 AM, Tong Li <li...@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 <lu...@redhat.com> wrote on 12/02/2011 07:57:17 PM:
>
>> From: David Lutterkort <lu...@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 <cu...@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.
>>
>>
>

Re: Proposal: add Apache Deltacloud to git scm

[Tong Li <li...@us.ibm.com>]

+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 <lu...@redhat.com> wrote on 12/02/2011 07:57:17 PM:

> From: David Lutterkort <lu...@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 <cu...@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.
>
>

Re: Proposal: add Apache Deltacloud to git scm

[Michal Fojtik <mf...@redhat.com>]

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