You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Daniel Kulp <dk...@apache.org> on 2009/12/02 20:39:21 UTC
Re: Status of Git at Apache
On Mon November 30 2009 4:50:15 pm Howard Lewis Ship wrote:
> The reality is that regardless of whether code comes in as patches in
> JIRA or as Git pull requests on GitHub, there is still a committer
> making the change and committing it to the "master" repository. Using
> Git instead of SVN does not affect the underlying process, especially
> as it concerns CLA.
I think you've kind of missed the issues that Jukka was describing.
As I see it, there are two main issues:
1) As you mentioned, we can easily ensure that only committers (that have
CLA's on file) can push to the master, git doesn't record WHICH committer that
was. It records the original author of the work. (where the committer
originally pulled the changes from) Thus, we'd have no way to track that
commit back to a PARTICULAR CLA.
2) We have no (standard) way to make sure that the original author of the work
(if they don't have a CLA on file) has given the OK to have the work included
in the Apache work. With JIRA, we have the "grant to Apache" checkbox for
the patch. Thus, if the commit message contains the JIRA ID (big if, wish
this was somehow more automatic), we can easily trace the commit back to both
the committer AND the original author and check the legal bits for both. If a
problem pops up, we have two names to contact immediately.
What's interesting is that the problem with git is the exact opposite of svn,
but I really think it's really still a problem for svn. With svn, unless the
committer puts something (like a jira ID) in the commit comment, we have a
committer ID, but not an author ID. With git, unless the "signed off by"
thing is used, we have a author id, but not a committer id. The "svn"
problem is more tolerable as the committer SHOULD at least have some idea
where the code came from. It's more in our control.
That said, we could probably put some hooks into the git repo that would do
some type of verification like:
1) if the author id is a committer id, OK it.
2) if the author id is NOT a committer id, require the "signed off by" thing
to be set and/or a JIRA ID (that would assumably have a patch attached with
the grant checkbox checked).
That would require someone to write the hooks, do thorough testing, etc...
That's not on infrastructures todo list at all.
Anyway, that all said, I'd LOVE to be able to use a central git repo instead
of svn as well. svn is painfully slow when your used to git.
Dan
> On Mon, Nov 30, 2009 at 1:43 AM, Greg Stein <gs...@gmail.com> wrote:
> > Jukka was working through the hosting issues. Last I heard, while at
> > ApacheCon a few weeks ago, was that it wasn't really possible for Git
> > to meet all the requirements. I don't recall what it is, but you're
> > talking things like recovery, authentication/authorization,
> > intercontinental replication/failover, etc.
> >
> > Personally, I find the notion of Apache developers working on private
> > git repositories (rather than the central svn repository) to be
> > anti-community. But I understand you can *make* git work in a more
> > communal and open fashion. But my opinion is neither here nor there.
> > The technical issues need to be solved first.
> >
> > Cheers,
> > -g
> >
> > On Sun, Nov 29, 2009 at 18:23, Howard Lewis Ship <hl...@gmail.com> wrote:
> >> Ok, what will it take to go beyond simple mirroring to full-fledged
> >> project hosting?
> >>
> >> On Sat, Nov 28, 2009 at 9:53 PM, Philip M. Gollucci
> >>
> >> <pg...@p6m7g8.com> wrote:
> >>> Howard Lewis Ship wrote:
> >>>>>From what I can tell, Git at Apache is limited to clones of Subversion
> >>>>
> >>>> repositories.
> >>>>
> >>>> The members of the Tapestry project are all very interested in using
> >>>> Git for day-to-day work on Tapestry. Are there any plans to set up
> >>>> read/write Git repositories at Apache? I haven't seen any useful
> >>>> information about this here, or on the Apache Board mailing list.
> >>>
> >>> There are no current plans to expand beyond what is available at
> >>> git.apache.org.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> -----------------------------------------------------------------------
> >>>- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
> >>> Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
> >>> VP Apache Infrastructure; Member, Apache Software Foundation
> >>> Committer, FreeBSD Foundation
> >>> Sr. System Admin, Ridecharge Inc.
> >>> Consultant, P6M7G8 Inc.
> >>>
> >>> Work like you don't need the money,
> >>> love like you'll never get hurt,
> >>> and dance like nobody's watching.
> >>
> >> --
> >> Howard M. Lewis Ship
> >>
> >> Creator of Apache Tapestry
> >>
> >> The source for Tapestry training, mentoring and support. Contact me to
> >> learn how I can get you up and productive in Tapestry fast!
> >>
> >> (971) 678-5210
> >> http://howardlewisship.com
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Status of Git at Apache
Posted by Howard Lewis Ship <hl...@gmail.com>.
There's definitely a bit of conflict going on here. On the one hand,
Apache's central message is all about community, but at the same time
(for the sake of the legal umbrella and CLA's) we are embracing a tool
(SVN) specifically to act as a choke point preventing community
involvement.
As a side note, I believe Ted Leung had a story at ApacheCon about the
loss of several months of Subversion commits and how, fortunately, he
had an archive of the commit mails and the knowledge to reapply all
the changes from those commit mails. In the world of Git, you could
follow that route, or recover official changes from any repository of
any committer or other user.
We've seen a side effect of Git's "code immortality" with Why the
Lucky Stiff, who deleted his online presence (including many GitHub
projects) a few months ago, but new GitHub projects were created from
other user's forks, losing none of his history.
The point is, it chagrins me to use a lesser tool, especially since
outside of one area, it does not address (from a technical
perspective) the goals of the Apache community.
On Wed, Dec 2, 2009 at 1:02 PM, Doug Cutting <cu...@apache.org> wrote:
> Howard Lewis Ship wrote:
>>
>> So what I'm hearing is that as long as external code is delivered via
>> a JIRA patch, and the JIRA issue is referenced in the commit, then
>> there's no difference between Git and SVN from a legal stand point.
>
> It's not black and white. The Jira signoff and even a CLA aren't strictly
> required, since the license itself says that its terms apply to anything
> that's intentionally submitted. However we like to have good documentation
> of that intent. Jira's checkbox provides this. The ICLA provides this.
>
> A concern with Git is that a committer might push and pull changes from
> others, work on them, then commit the collaboratively produced code, with no
> clear point to document the intent of those others.
>
> Of concern with this pattern is, as mentioned, the decreased documentation
> of intent. But also of concern is the decreased visibility of these
> interactions to the community. With subversion+Jira, a project has a single
> patch repository and a single source code repository that all interactions
> go through, so that any member of the community can monitor progress on
> every issue in a single place. But, when folks are collaborating in a
> distributed manner there's no longer a single point to monitor: to track the
> project one must monitor the individual Git repos of each developer.
>
> To use an analogy, it's a bit like C++'s operator overloading, which I view
> as a bad idea (pretend you agree with me, for the sake of this discussion).
> In C++ projects you need to enforce a coding guideline against using this
> language feature. In Java projects you have no such need, since Java simply
> doesn't have operator overloading. Similarly, Subversion doesn't easily
> support distributed development, while Git does. The ASF wishes to
> discourage distributed development and is thus wary of embracing Git as a
> primary tool.
>
> Finally, there's the infra issue: subversion is our highest priority
> service, the one infra works hardest to keep running reliably without data
> loss. Properly supporting another source code management system would not
> be free and would spread our infrastructure resources even more thinly and
> can thus not be considered lightly.
>
> Doug
>
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Status of Git at Apache
Posted by Marvin Humphrey <ma...@rectangular.com>.
> > Perhaps someone will create a good Apache-specific cheat sheet.
I would appreciate, use, and help revise such a document.
With medium-sized or large contributions, I prefer to structure things as a
series of small patches rather than a single mondo patch -- that way, the
contribution is easier for other community members to review. I haven't yet
found the time to get past git's initial learning curve, but from what I
understand, git-svn would make that workflow simpler.
First hint:
Depending on how git was installed, git-svn may not be in your path. If
git-svn is available but not accessible, "git svn" may work instead.
(This is the situation if you use the current version of
<http://code.google.com/p/git-osx-installer/>.)
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Status of Git at Apache
Posted by Howard Lewis Ship <hl...@gmail.com>.
I meant to reply to the list.
On Thu, Dec 3, 2009 at 8:28 AM, Doug Cutting <cu...@apache.org> wrote:
> Howard Lewis Ship wrote:
>>
>> If you haven't used Git extensively, you should try it.
>
> I have tried it. It is fast, but I couldn't manage to get it to work
> seamlessly in my workflow, keeping a branch per patch, re-syncing these with
> trunk, and using git-svn to commit a branch back to trunk. Like Eclipse, it
> would probably make my life easier in the long run once I got over the
> learning hump, but I've not had the time to do so. Perhaps someone will
> create a good Apache-specific cheat sheet.
>
> (Did you mean to reply to the list or not?)
>
> Doug
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Status of Git at Apache
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Wed, Dec 2, 2009 at 11:39 AM, Daniel Kulp <dk...@apache.org> wrote:
> On Mon November 30 2009 4:50:15 pm Howard Lewis Ship wrote:
>> The reality is that regardless of whether code comes in as patches in
>> JIRA or as Git pull requests on GitHub, there is still a committer
>> making the change and committing it to the "master" repository. Using
>> Git instead of SVN does not affect the underlying process, especially
>> as it concerns CLA.
>
> I think you've kind of missed the issues that Jukka was describing.
>
> As I see it, there are two main issues:
>
> 1) As you mentioned, we can easily ensure that only committers (that have
> CLA's on file) can push to the master, git doesn't record WHICH committer that
> was. It records the original author of the work. (where the committer
> originally pulled the changes from) Thus, we'd have no way to track that
> commit back to a PARTICULAR CLA.
>
> 2) We have no (standard) way to make sure that the original author of the work
> (if they don't have a CLA on file) has given the OK to have the work included
> in the Apache work. With JIRA, we have the "grant to Apache" checkbox for
> the patch. Thus, if the commit message contains the JIRA ID (big if, wish
> this was somehow more automatic), we can easily trace the commit back to both
> the committer AND the original author and check the legal bits for both. If a
> problem pops up, we have two names to contact immediately.
>
>
> What's interesting is that the problem with git is the exact opposite of svn,
> but I really think it's really still a problem for svn. With svn, unless the
> committer puts something (like a jira ID) in the commit comment, we have a
> committer ID, but not an author ID. With git, unless the "signed off by"
> thing is used, we have a author id, but not a committer id. The "svn"
> problem is more tolerable as the committer SHOULD at least have some idea
> where the code came from. It's more in our control.
>
> That said, we could probably put some hooks into the git repo that would do
> some type of verification like:
> 1) if the author id is a committer id, OK it.
>
> 2) if the author id is NOT a committer id, require the "signed off by" thing
> to be set and/or a JIRA ID (that would assumably have a patch attached with
> the grant checkbox checked).
>
I'm pretty sure that when using the sign off option, both you (the
committer) and the contributor (the author) are identified.
> That would require someone to write the hooks, do thorough testing, etc...
> That's not on infrastructures todo list at all.
>
>
> Anyway, that all said, I'd LOVE to be able to use a central git repo instead
> of svn as well. svn is painfully slow when your used to git.
>
> Dan
>
>
So what I'm hearing is that as long as external code is delivered via
a JIRA patch, and the JIRA issue is referenced in the commit, then
there's no difference between Git and SVN from a legal stand point.
>
>
>> On Mon, Nov 30, 2009 at 1:43 AM, Greg Stein <gs...@gmail.com> wrote:
>> > Jukka was working through the hosting issues. Last I heard, while at
>> > ApacheCon a few weeks ago, was that it wasn't really possible for Git
>> > to meet all the requirements. I don't recall what it is, but you're
>> > talking things like recovery, authentication/authorization,
>> > intercontinental replication/failover, etc.
>> >
>> > Personally, I find the notion of Apache developers working on private
>> > git repositories (rather than the central svn repository) to be
>> > anti-community. But I understand you can *make* git work in a more
>> > communal and open fashion. But my opinion is neither here nor there.
>> > The technical issues need to be solved first.
>> >
>> > Cheers,
>> > -g
>> >
>> > On Sun, Nov 29, 2009 at 18:23, Howard Lewis Ship <hl...@gmail.com> wrote:
>> >> Ok, what will it take to go beyond simple mirroring to full-fledged
>> >> project hosting?
>> >>
>> >> On Sat, Nov 28, 2009 at 9:53 PM, Philip M. Gollucci
>> >>
>> >> <pg...@p6m7g8.com> wrote:
>> >>> Howard Lewis Ship wrote:
>> >>>>>From what I can tell, Git at Apache is limited to clones of Subversion
>> >>>>
>> >>>> repositories.
>> >>>>
>> >>>> The members of the Tapestry project are all very interested in using
>> >>>> Git for day-to-day work on Tapestry. Are there any plans to set up
>> >>>> read/write Git repositories at Apache? I haven't seen any useful
>> >>>> information about this here, or on the Apache Board mailing list.
>> >>>
>> >>> There are no current plans to expand beyond what is available at
>> >>> git.apache.org.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> -----------------------------------------------------------------------
>> >>>- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
>> >>> Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
>> >>> VP Apache Infrastructure; Member, Apache Software Foundation
>> >>> Committer, FreeBSD Foundation
>> >>> Sr. System Admin, Ridecharge Inc.
>> >>> Consultant, P6M7G8 Inc.
>> >>>
>> >>> Work like you don't need the money,
>> >>> love like you'll never get hurt,
>> >>> and dance like nobody's watching.
>> >>
>> >> --
>> >> Howard M. Lewis Ship
>> >>
>> >> Creator of Apache Tapestry
>> >>
>> >> The source for Tapestry training, mentoring and support. Contact me to
>> >> learn how I can get you up and productive in Tapestry fast!
>> >>
>> >> (971) 678-5210
>> >> http://howardlewisship.com
>>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org