Thanks for the advice, you are raising some very valid points.
In our monthly meetings we’re committers from 3 companies, and we agreed that adding releng expertise would benefit the project. We also agreed that voting
for a committer without public track record should be a one-off exception, but justified in this case since proving releng capacity while not being on the project is much harder than contributing a code patch – and the case was urgent in light of the required
move from CVS to git.
We would monitor his contributions and be ready to “de-committerize” quickly in case he were found disruptive (according to tools PMC charter: “A Committer
that is disruptive […] may have his or her commit status removed by the PMC.”)
We didn’t discuss the concrete circumstances and hope this won’t happen, but codifying a single committer’s “-1” for such a case might make sense. When Jose’s contributions are good, we’d consider the public track record to be evident after the fact.
With CBI making builds easy to reproduce anywhere, I believe that moving forward releng tasks won’t fall in a different category than code patches any more.
But with the legacy builds we still have in place for old streams this is unfortunately still the case. Most of Jose’s work will be migrating these legacy builds to CBI in order to support git.
Summing up,
-
This should not become precedent
-
Committer diversity on the project is important for this to be acceptable
-
We discussed it on phone and came up with a mitigation plan (just in case)
-
It will be less of an issue in the future.
Thanks for your support in this case.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: tools-pmc-bounces@xxxxxxxxxxx [mailto:tools-pmc-bounces@xxxxxxxxxxx]
On Behalf Of John Duimovich
Sent: Friday, October 05, 2012 10:57 PM
To: Tools PMC mailing list
Subject: Re: [tools-pmc] Adding a committer for releng tasks ?
This is a fairly common request, especially releng and maintain tasks but is a slippery slope as Dave notes.
Given you plan a full committer vote and they will have to live with the results - I'm ok with it but only because the committers are not all from the one company and the vote would indicate that
you've convinced enough of the cross-company committer group to agree this is the right thing for your project
I would have a different reaction to a single company project - as these kinds of moves appear less open, and would discourage external participation.
+1
John
From: David M Williams <david_williams@xxxxxxxxxx>
To: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>
Date: 10/05/2012 04:38 PM
Subject: Re: [tools-pmc] Adding a committer for releng tasks ?
Sent by: tools-pmc-bounces@xxxxxxxxxxx
I won't object to this, but would consider it an exception that should not be considered a precedent.
I mean ... not one patch attached to any bug? Not one bug reported anywhere? Not one wiki page? How about a document of what the plan to convert/move/migrate/maintain is? Seems like there could/should be some easy concrete contribution to point to, it is not
that hard.
Again, I won't object, but I don't know where the line is. Such as, what if Jose ... just hypothetically ... were to change jobs. Would he stay on as a committer and do the work? Or is it his "position" that leads to this and if someone else took his position
at IBM would they then be expected to be "voted in" without any public record?
Again, I won't object ... but ... wanted to emphasize that "contributions" don't have to be huge or complex ... and would hate to see this become the norm.
Thanks for asking.
From: Martin Oberhuber <martin.oberhuber@xxxxxxxxxxxxx>
To: <tools-pmc@xxxxxxxxxxx>,
Date: 10/04/2012 02:11 AM
Subject: [tools-pmc] Adding a committer for releng tasks ?
Sent by: tools-pmc-bounces@xxxxxxxxxxx
Greetings Tools PMC,
In the TM project, we're thinking about adding a person (Jose Manuel Garcia Maciel of IBM) for release engineering tasks, particularly migrating / maintaining legacy builds of old streams after our upcoming git migration.
In order to make sure that his tasks work smoothy without unnecessary blockers, we'd propose making him a committer.
Jose has no public track record of any contributions so far, but we discussed the situation with the current active committers today and would be OK with him becoming committer. His rights would be restricted to releng by social convention.
I know that there have been precedent cases like this with other projects, and think that this should work if the project is OK (via normal committer vote). Just wanted to check back with you whether you see any roadblocks from the Foundation / Dev Process
point of view.
Wayne was OK with this but suggested I also ping the Tools PMC.
Thanks,
Martin
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
