corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Criteria for becoming committer in Corinthia.
Date Sat, 01 Aug 2015 17:49:50 GMT
On 1 August 2015 at 17:26, Peter Kelly <> wrote:

> > On 28 Jul 2015, at 9:24 pm, jan i <> 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.

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
> PGP key: <>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

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