commit rights ...

[Mojca Miklavec]

On Thu, Mar 6, 2014 at 2:28 PM, Rainer Müller wrote:
> If someone else is being able to commit more
> time for MacPorts I would give up my position or we go back to four port
> managers.

I don't see why anyone would need to give up the position. What's
wrong with simply adding one person?

> Another option would be to revise the commit access application
> completely. For example, it could be done in public on macports-dev
> instead of letting portmgr handle them in private.

I understand the private nature of the process to some extent. It
could be bad to tell someone that he/she is not good enough yet on a
public mailing list.

(A private list without [public] archives with just committers would
also be ok.)

> A simple system could
> be that the applicant needs three sponsors/warrantors from the existing
> developers for any applicant until he/she gets commit access.

I love that idea.

I wrote a reply yesterday, but sent it from the wrong email address,
so it didn't reach the mailing list. See below. But the idea of
sponsors is a lot more appealing and a lot easier to "implement" than
what I wrote below. And the process could stay non-public if needed.


On Wed, Mar 5, 2014 at 8:06 PM, Daniel J. Luke wrote:
> IIRC there were supposed to be regular (annual?) portmgr elections to make sure the people on it were ones the community of committers wanted, and to make sure they were people who had enough time to dedicate to the project.
>
> If we've got portmgr members who don't have time, to review committer applications, then it would be nice if they would step down (or be moved to the elder council) so that someone with time could take on additional responsibilities (assuming that there is someone interested in joining portmgr).

There is no need for anyone to step down (unless there is a rule that
everyone needs to agree on every decision or if there is really a
restricted number of places for some reason). A few more people could
simply join the portmgr group, or at least one with a bit of extra
time.

There might be another "problem" though. When I wanted to apply for
commit rights, I found it "difficult" enough to find all my relevant
contributions. It must be even more difficult for the portmgr group to
do research on every applicant. If the managers had better tools, it
would probably be easier.

Or the very rare occasions when I commit someone else's patch, I would
gladly place some kind of a "vote" with some semi-automated messages
like "dear portmgr, I just committed r[XXXXX] from ticket #[XXXXX],
the author of the patch did a [N] star job. I (basically had to
rewrite everything myself)/(needed to do many modifications)/(had to
some a couple of modifications)/(only fixed some trivial issues)/(just
committed everything as-is)/(this was a very advanced patch or
contribution). Based on this I would say that (the author needs to
learn a bit more)/(I have no opinion)/(I would propose to grant commit
right)/(I strongly support granting commit rights based also on
history of other patches and contribution I've seen)".

If the team would see a lot of positive or extremely positive votes
coming from other experienced committers, it would simplify their work
a lot.

Even experienced committers make mistakes, and postponing the decision
about commit rights makes more burden on those.

That said, I have a list of people on top of my head for which I would
vote for granting them commit rights, but Eric G. is definitely on top
of that list.

Mojca