You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by Peter Kelly <pm...@apache.org> on 2015/08/01 17:26:36 UTC

Re: Criteria for becoming committer in Corinthia.

> On 28 Jul 2015, at 9:24 pm, jan i <ja...@apache.org> wrote:
> 
> Hi.
> 
> As was obvious from other discussions (in private), we need to agree on
> what are the "rules"
> for being accepted as a committer. It is also obvious that there are room
> for diversity in how
> we apply the rules.
> 
> For me life is very simple, we are a small project, and should use any
> chance to grow. This
> means, I believe we should look at:
> 
> 1) Candidate has been active on dev@ and shown interest for the project
> 2) Candidate has submitted patches (not necessarily through dev@)
> 3) Candidate has otherwise done work to help corinthia.

I think that fulfilling either of these three criteria to a sufficient extent makes sense as criteria. I think these should be guidelines to help people make their judgements however, not necessarily an automatic conclusion, not least of which is that opinions about what considers “sufficient” effort will differ.

I think we should also add participation on JIRA issues to this list. I would consider that we should see both communication and code from a potential new committer in order to make a judgement. JIRA is an important mode of communication aside from the mailing list. And of course evidence of (non-trivial) coding work, especially when it’s done on the candidate’s own initiative, would in my mind speak strongly in favour of a +1.

Regarding patches and attribution: Git has the ability to make a commit where the identities of the author and committer are distinct. For example if Linus Torvalds sends me a patch, and I decide it’s good enough to accept, then I can use the —author option on git commit so that it’s recorded it was Linus’s work, not mine; I just put it in the repository. This will help in tracking who has done what, and a non-committer’s patch doesn’t get incorrectly attributed to the committer themselves.

—
Dr Peter M. Kelly
pmkelly@apache.org

PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)


Re: Criteria for becoming committer in Corinthia.

Posted by jan i <ja...@apache.org>.
On 1 August 2015 at 17:26, Peter Kelly <pm...@apache.org> wrote:

> > On 28 Jul 2015, at 9:24 pm, jan i <ja...@apache.org> wrote:
> >
> > Hi.
> >
> > As was obvious from other discussions (in private), we need to agree on
> > what are the "rules"
> > for being accepted as a committer. It is also obvious that there are room
> > for diversity in how
> > we apply the rules.
> >
> > For me life is very simple, we are a small project, and should use any
> > chance to grow. This
> > means, I believe we should look at:
> >
> > 1) Candidate has been active on dev@ and shown interest for the project
> > 2) Candidate has submitted patches (not necessarily through dev@)
> > 3) Candidate has otherwise done work to help corinthia.
>
> I think that fulfilling either of these three criteria to a sufficient
> extent makes sense as criteria. I think these should be guidelines to help
> people make their judgements however, not necessarily an automatic
> conclusion, not least of which is that opinions about what considers
> “sufficient” effort will differ.
>
> I think we should also add participation on JIRA issues to this list. I
> would consider that we should see both communication and code from a
> potential new committer in order to make a judgement. JIRA is an important
> mode of communication aside from the mailing list. And of course evidence
> of (non-trivial) coding work, especially when it’s done on the candidate’s
> own initiative, would in my mind speak strongly in favour of a +1.
>
please remember not all committers are programmers. We will hopefully soon
have testers/documenters/buildbot maintainers etc. so we must take care not
to focus
being committer around having done git commit.

rgds
jan i.


>
> Regarding patches and attribution: Git has the ability to make a commit
> where the identities of the author and committer are distinct. For example
> if Linus Torvalds sends me a patch, and I decide it’s good enough to
> accept, then I can use the —author option on git commit so that it’s
> recorded it was Linus’s work, not mine; I just put it in the repository.
> This will help in tracking who has done what, and a non-committer’s patch
> doesn’t get incorrectly attributed to the committer themselves.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>

Re: Criteria for becoming committer in Corinthia.

Posted by jan i <ja...@apache.org>.
On 1 August 2015 at 19:39, Andrea Pescetti <pe...@apache.org> wrote:

> On 01/08/2015 Peter Kelly wrote:
>
>> Regarding patches and attribution: Git has the ability to make a
>> commit where the identities of the author and committer are distinct.
>>
>
> All revision control systems have logs anyway, so proper attribution is
> always possible by means of a convention like
> http://openoffice.apache.org/svn-basics.html#committing_changes_by_others
>
> It is not nearly as elegant as having it natively, but much better than
> completely omitting it.
>
+1, I am all for we adapt that scheme, we are anyhow only a few that commit
patches from others, so it should not be hard.

Attribution is important, so omitting it is not an option from my pow.

rgds
jan i.


>
> Regards,
>   Andrea.
>

Re: Criteria for becoming committer in Corinthia.

Posted by Andrea Pescetti <pe...@apache.org>.
On 01/08/2015 Peter Kelly wrote:
> Regarding patches and attribution: Git has the ability to make a
> commit where the identities of the author and committer are distinct.

All revision control systems have logs anyway, so proper attribution is 
always possible by means of a convention like
http://openoffice.apache.org/svn-basics.html#committing_changes_by_others

It is not nearly as elegant as having it natively, but much better than 
completely omitting it.

Regards,
   Andrea.