Mailing-List: contact infrastructure-dev-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: infrastructure-dev@apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer;
  b=jAv/fMi10BK4fisdPVPJI52we23KvBrOOBGcHq/WUp/chfEtbSgCP/O7u4PIOoCzBbnQyguiEdGn3qLnK38QILic8+VVk+h1VLr6os2kGRUT6Ud0RSxZ/csNI+Mz4tbXxGq4V/hDNPVQ19YrTwQfM3YFw9774i/ycvUHFrNJddQ=
  ;
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: @apache.org commit address requirement (Was: Git hosting is go)
From: David Jencks <david_jencks@yahoo.com>
In-Reply-To: 
 <CAJ_m3YBtLpBpysioo9JOxo2t_OT9nZVXCwWejRTiobNw30=-wA@mail.gmail.com>
Date: Tue, 20 Dec 2011 19:08:14 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <EDB77774-1D4B-4E64-9358-FADDD2E64410@yahoo.com>
References: 
 <CAOFYJNaM2b5yO=2TCM-qv2Sa9zN_pzYUCb+m91sFC=WD+y5QeA@mail.gmail.com>
 <CAJ_m3YBFLHhoeXn+_SYHCmMMFsL7osZFG=2d6RwSuuTSeYM5fg@mail.gmail.com>
 <CAOFYJNZJnFbL3-aXABN=30+w3-dyTz_rHy5RiN9cjJTHMCo79g@mail.gmail.com>
 <CAJ_m3YD-MZjRsKKvfhk8JddKBaxohY6kQEAdfVEmCuMEfqH0Bw@mail.gmail.com>
 <CAOFYJNbXDWKChTMG6CJCALxU3LTS3Xw9Sv2wSYCB2SSRFpkv-Q@mail.gmail.com>
 <CAJ_m3YACwsP5OFYdWA=grbySGCPVpoYdKPiL3ga93EijC0GjiA@mail.gmail.com>
 <CAOFYJNZz+WgXFuUEV+9e+g9HymR=5gTDwoxd_aOO-R_N2v4-9w@mail.gmail.com>
 <CAJ_m3YDeQ1=sXKG77F9Fokj=yA8=UfFX4o2_V_OHFh2vFJ+orQ@mail.gmail.com>
 <8FFCC1B8-280E-4003-90C2-24246AAA1EDD@gbiv.com>
 <CAJ_m3YBM2cu-a6ZxMfkmKb5CEXo8=dfnzSuZEZwqd1TY4q7ckw@mail.gmail.com>
 <CAJ_m3YAidYOMbB4SBNC-Z_Ut4fcH5vQ478RMqJC+03uTJnfHGw@mail.gmail.com>
 <CAOFYJNbekBScwi65yLrfe1VShf8EkhYxabOVoWVA4E1zk2ueNw@mail.gmail.com>
 <CAJ_m3YBfiyLNR_4rCa0HxXJfWRe3V4d3jESsonRu_w38gUk2-g@mail.gmail.com>
 <CAOFYJNboAF=SfT-g67hvxL8wYsKgLC0inFxb=p0wRM2VBTK77g@mail.gmail.com>
 <CADVmKVAWGUWdzN+K9+HDoSGiCbiR3NK
 TCFPdCTw=Q_mP7w7Vtg@mail.gmail.com>
 <CAJ_m3YCbhr-UDquEgR+jy5m_MuToV4ZC-m2O2yos33w=Xu9oWw@mail.gmail.com>
 <3CDC4B29-BE30-45CE-A28A-22C171FC45CA@yahoo.com>
 <CAJ_m3YBtLpBpysioo9JOxo2t_OT9nZVXCwWejRTiobNw30=-wA@mail.gmail.com>
To: infrastructure-dev@apache.org


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:
>>=20
>> On Dec 20, 2011, at 3:48 PM, Paul Davis wrote:
>>=20
>>> 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:
>>>>=20
>>>>> On Mon, Dec 19, 2011 at 5:15 PM, Jukka Zitting =
<jukka.zitting@gmail.com>
>>>>> wrote:
>> <giant snip>
>>>=20
>>> 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.
>>>=20
>>=20
>> What exactly do you mean by "patch moves through jira" for git?
>>=20
>=20
> 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.
>=20
>> 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.
>>=20
>=20
> 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


>=20
>> 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.
>>=20
>> thanks
>> david jencks
>>=20
>>=20
>=20
> 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.
>=20
> [1] https://github.com/eevans/git-jira-attacher/