www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: @apache.org commit address requirement (Was: Git hosting is go)
Date Wed, 21 Dec 2011 03:08:14 GMT

On Dec 20, 2011, at 5:46 PM, Paul Davis wrote:

> On Tue, Dec 20, 2011 at 7:03 PM, David Jencks <david_jencks@yahoo.com> wrote:
>> 
>> On Dec 20, 2011, at 3:48 PM, Paul Davis wrote:
>> 
>>> On Tue, Dec 20, 2011 at 2:22 PM, Jeremy Thomerson
>>> <jeremy@thomersonfamily.com> wrote:
>>>> On Tue, Dec 20, 2011 at 3:04 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:
>>>> 
>>>>> On Mon, Dec 19, 2011 at 5:15 PM, Jukka Zitting <jukka.zitting@gmail.com>
>>>>> wrote:
>> <giant snip>
>>> 
>>> Once again I'm going to point out that current patches must move
>>> through JIRA. Assuming people follow this policy then the %ce field is
>>> by definition an ASF committer on the Apache project in question. Full
>>> stop.
>>> 
>> 
>> What exactly do you mean by "patch moves through jira" for git?
>> 
> 
> Ie, the patch goes to JIRA, the ASF committer the downloads the patch
> from JIRA, applies, reviews, and then if it checks out, finally pushes
> it to master (or where ever is appropriate for integration based on
> that project's workflows). Cassandra has scripts [1] that automate
> most of this.
> 
>> I think it means that there's a jira issue in apache jira with a  pointer to the
(set of) git commits and the commit message in git has the jira #.  On the projects I work
with (with svn) the mention of the jira in the commit message results in jira being able to
link to the changes, and we expect all committers to have a jira issue for all non-trivial
changes.  I hope the same will be true for git.  I think a pointer to the git change set in
some repo is equivalent to attaching a patch to a jira issue.
>> 
> 
> I'm not sure how a pointer to some change set satisfies the policy.
> The underlying motivation for submitting the patch to JIRA is to
> indicate "I submit this code to be included under the ASL 2.0" which
> doesn't seem to hold up if the code isn't actually attached to the
> ticket with the little check box clicked.

doesn't the hash identify the contribution well enough?  Are you worried about hash collisions?
 Or that the external repo might disappear?  When does moving the work into apache git change
the hash?

If we're talking about other ways of applying work from outside asf to inside how do these
concerns differ?  They seem totally unrelated to the concerns previously expressed in this
thread.

thanks
david jencks


> 
>> I'm really not understanding what the point of doing anything other than checking
that the person who pushes the work into the asf repository is an asf committer on the project.
 That's all we do for svn, right?  We can do reports or whatever on the additional git metadata
but until there's a demonstrated problem I don't see why we need to solve it.
>> 
>> thanks
>> david jencks
>> 
>> 
> 
> Git is not the same as SVN. This is specifically dealing with the
> distributed nature of Git and how we can deal with enforcing
> constraints on code uploaded to ASF canonical repos that may have come
> from anywhere. As I've tried to point out if we're just going to
> maintain the same policies we have for SVN then this is all moot
> because patches would have to be applied by hand instead being pulled
> from arbitrary remote repos. The entire motivation for having these
> checks is to maintain the provenance for contributions without
> requiring that every patch moves through JIRA.
> 
> [1] https://github.com/eevans/git-jira-attacher/


Mime
View raw message