incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Advice on policy merging non-committer branches
Date Sun, 04 Mar 2012 20:47:07 GMT
Thanks Jason!

On Sun, Mar 4, 2012 at 9:35 AM, Jason Smith <jhs@iriscouch.com> wrote:

> Converted to a wiki page: http://wiki.apache.org/couchdb/CommitPolicy
>
> On Sun, Mar 4, 2012 at 2:42 AM, Paul Davis <paul.joseph.davis@gmail.com>
> wrote:
> > Noah,
> >
> > Sure, let me write that up and send it in an email to dev@.
> >
> > Paul
> >
> > On Sat, Mar 3, 2012 at 7:33 PM, Noah Slater <nslater@tumbolia.org>
> wrote:
> >> Paul, can you document this somewhere? It looks like a great candidate
> for
> >> our Git proposal to the ASF.
> >>
> >> On Wed, Feb 29, 2012 at 4:34 AM, Paul Davis <
> paul.joseph.davis@gmail.com>wrote:
> >>
> >>> On Tue, Feb 28, 2012 at 9:57 PM, Jason Smith <jhs@apache.org> wrote:
> >>> > I would like to merge a branch from a non-committer[1]. The log shows
> >>> > a non-apache author, but an apache committer.
> >>> >
> >>> > What is the policy regarding this? I was thinking the following:
> >>> >
> >>> > 1. Merge freely and promiscuously from anybody in my GitHub (or
> >>> > whatever) repo (community engagement)
> >>>
> >>> Not quite. More below.
> >>>
> >>> > 2. As the branch nears time for "promotion," ask the non-committer
to
> >>> > git format-patch and attach to JIRA, signing (checking) the license
> >>> > transfer.
> >>>
> >>> Unnecessary.
> >>>
> >>> > 3. With that settled, either git rebase or `git am` (I'm unclear
> about
> >>> > this). The point is, get an @apache.org committer id on each commit.
> >>>
> >>> Unnecessary.
> >>>
> >>> > 4. Push where appropriate into the ASF repo
> >>> >
> >>>
> >>> Included in discussion of 1 below.
> >>>
> >>> > Questions:
> >>> >
> >>> > Must the non-committer attach the exact same commit id? Or is it
> >>> > sufficient that it merely be the same diff (delta)? (I changed the
ID
> >>> > when I rebased his commit and added my email to the committer
> header.)
> >>> >
> >>>
> >>> No. Commit SHA's are in no way important from a license perspective.
> >>>
> >>> > Before the JIRA license agreement, may we push non-committers' code
> to
> >>> > the repo at all?
> >>> >
> >>>
> >>> Kinda, see below.
> >>>
> >>> > Before the JIRA license agreement, may we push non-committers' code
> to
> >>> > the more official branches: master, 1.2.x, etc.?
> >>> >
> >>> > May we push whatever we want so long as the license agreement is
> >>> > signed (checked) before voting on a release artifact?
> >>>
> >>> For the last two questions, definitely not. Never push code to ASF
> >>> hardware that you're not 100% certain is OK to be in the repository.
> >>> That doesn't necessarily mean that it has to have the ASF license
> >>> attached, but if you don't know that it can be in the repo, don't push
> >>> it.
> >>>
> >>> First things first, as a committer you have to remember the ICLA that
> >>> you signed. Its your responsibility to make sure that all code you
> >>> push to the repository is compliant with ASF policies and the legal
> >>> aspects those entails.
> >>>
> >>> Before Git, the general policy we used in CouchDB was to request that
> >>> non-trivial patches be submitted to JIRA and have people click the
> >>> checkbox. While this captures the general intent of things, it has
> >>> been declared an official position of the board that this is
> >>> unnecessary for accepting contributions. It has also been decided that
> >>> the committer and author fields do not have to be tied to specific
> >>> Apache accounts.
> >>>
> >>> The policy as it stands now is that we must be able to demonstrate
> >>> that there was a clear intent for the code in question to be
> >>> contributed. While there hasn't been an official position on how to
> >>> demonstrate intent I think there are a couple things that are fairly
> >>> obvious:
> >>>
> >>> Traditional:
> >>>
> >>> 1. Same as always: Anything submitted to JIRA. The check box has been
> >>> declared not a necessity though I think the input field is required,
> >>> and if someone said "not-intended for inclusion" we should just
> >>> clarify if that was an accident or not.
> >>>
> >>> 2. Patches submitted to a mailing list.
> >>>
> >>> New with Git:
> >>>
> >>> 3. If someone posts a link to a publicly available Git branch with
> >>> language indicating their intent for it to be included, then we should
> >>> feel free to add the repo as a remote and yank it in. While not
> >>> absolutely necessary, it might be a good idea to rewrite the commit
> >>> message to reference either the email or the original contributed
> >>> commit sha (in case of a rebase) so that we can link the two.
> >>>
> >>> 4. Jukka Zitting has recently been doing work on connecting GitHub
> >>> Pull Requests to the dev@ mailing lists. Assuming this is the case I
> >>> think we should feel free to take any code submitted in this manner.
> >>> Thus our old "Submit that to JIRA" would be a "Send us a Pull
> >>> Request".
> >>>
> >>> In contrast, we shouldn't feel free to just find code in a random
> >>> GitHub fork and push that onto ASF hardware. If there's something we
> >>> see that we want then we should ask for clarification (plus that's
> >>> only polite).
> >>>
> >>> Bottom line, as a committer you're responsible for the code that you
> >>> push to the repository. If you're not sure on a specific patch or
> >>> situation, bring it up to dev@ or similar venue and we can run it up
> >>> the flag pole until we find an answer.
> >>>
>
>
>
> --
> Iris Couch
>

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