www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Thomerson <jer...@thomersonfamily.com>
Subject Re: @apache.org commit address requirement (Was: Git hosting is go)
Date Wed, 21 Dec 2011 18:19:23 GMT
On Wed, Dec 21, 2011 at 1:13 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

> On Wed, Dec 21, 2011 at 7:35 AM, Jeremy Thomerson
> <jeremy@thomersonfamily.com> wrote:
> > On Wed, Dec 21, 2011 at 5:12 AM, Brett Porter <brett@apache.org> wrote:
> >
> >> > IOW, if I receive a pull request or changeset on a public list from a
> >> > contributor that does not have a CLA on file, I want to preserve that
> >> > changeset exactly as contributed so that the commit log will
> >> automatically
> >> > refer to that third-party and the hash can be used to search for their
> >> > contribution request.  I would only want to modify the changeset
> >> > and provide a new log entry for those few cases where the existing
> >> > information is not sufficient to satisfy my own CLA. [And, for that
> >> > case, we should make it a good practice to include the original
> changeset
> >> > identifier in the new log entry.]
> >>
> >> Thanks - that's a much clearer justification than keeping the committer
> >> intact, which I hadn't gleaned from the earlier conversation.
> >>
> >> My limited experience with external contributions has been mixed between
> >> pull requests being merged and rebased, and I got the impression
> rebasing
> >> was used more often than perhaps it is. I also don't tend to maintain a
> >> repo that diverges from the "central" one, so I'm not too concerned
> about
> >> the commit IDs on mine.
> >
> >
> > Roy's description above is the exact reason that I am in favor of
> removing
> > the "push hook" (or making it optional per-project).  I would like to
> see a
> > future workflow where:
> >
> > 1 - someone emails our dev list saying "please merge commit ABC123 from
> my
> > repo http://example.org/...
> > - or -
> > 1 - someone creates a pull request on GH, and this gets emailed to our
> dev
> > list
> >
> > 2 - we merge their commits in unchanged
> >
> > By doing so, we have clear "intent to contribute" with the hash of their
> > commit(s).
> >
> > Additionally, there's a huge benefit to keeping the commit IDs the same.
>  I
> > just tested this with my own playground repo.  Someone created a GH pull
> > request [1].  I did *not* use the GH interface to close it.  Instead I
> > manually added their repo and merged their commits (by commit ID).  Then
> I
> > pushed to my repo.  The pull request automatically closed.  This means
> that
> > we can fully integrate ASF projects with GH pull requests without having
> to
> > use the GH UI or use it as canonical, etc.  And, we have very clear
> "intent
> > to contribute" because if they create a pull request on GH, they are
> > explicitly asking us to contribute them.  We'll want those archived on
> our
> > hardware (mailing list message would be sufficient), but it's a very easy
> > flow that involves little in the way of integration.  I have some ideas
> to
> > make this a very simple process for our committers - but I'll leave that
> > for another thread.
> >
> > So, can we please remove the current restriction or make it a
> configuration
> > option?
> >
> > [1] https://github.com/jthomerson/github-playground/pull/1
> >
> > Jeremy
>
> Yup. Removed:
>
>
> https://git-wip-us.apache.org/repos/infra?p=asfgit-admin.git;a=commitdiff;h=85c6f83f832fc4a13315b1225d27038215db63d5
>

Thanks Paul!  When you commit a change there does it automatically get
pushed to the actual git hosting?  Or do you have to do that manually?

I'd still like to have a better community consensus around the
understanding of CLA requirements, but I don't think that needs to
(continue) happen(ing) on the infra-dev list.

Jeremy Thomerson

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message