www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: @apache.org commit address requirement (Was: Git hosting is go)
Date Wed, 21 Dec 2011 03:25:07 GMT
On Tue, Dec 20, 2011 at 9:08 PM, David Jencks <david_jencks@yahoo.com> wrote:
>
> 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?
>

Not necessarily. No. Yes. Depends.

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

I'm not sure what you're asking here so I can't comment.

> 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