I've chatted with Denis, and he is not opposed to putting the infrastructure in place to allow bug-triage permissions to be granted to non-committers.
He said this gets discussed occasionally, but no one ever pushes for it. His only concern (I think) was people being granted this authority, but then never removed, even when they no longer play that role. So, Project Leads and PMC members will have to "monitor" this bug-triage list, just as they do inactive committers. While Denis could not yet give an exact estimate of when the work could be completed, sounded like it would be "in March". So, the individuals in question could start to carry out that role in a month, or so.
Accordingly, I've opened feature request 265880. Please vote, follow, and comment on that entry if there are bug-triage issues I haven't captured.
On the larger, longer term issue of where we should draw the line between committers and contributors, I double checked the Eclipse Development Process documentation, and it is pretty explicit.
Each Project has a Development Team, led by the Project Leaders. The Development Team is composed of Committers and Contributors. Contributors are individuals who contribute code, fixes, tests, documentation, or other work that is part of the Project. Committers have write access to the source code repository(ies) of the Project and are expected to influence the Project's development.
I believe we at Eclipse sometimes do not give proper recognition to the _whole_ development team ... that is, we sometimes act like the "committers" are the whole development team ... but, if we are to follow the development process, we should look for ways to recognize contributors in ways other than making them committers. I don't have an easy answer for that. But, I think that should be our direction, and keep 'committers' to it's long held meaning of "write access to the source code repository(ies)". This isn't as arbitrary as it may sound, as it is those with write access to CVS that are contributing Intellectual Property to Eclipse, and which are responsible for carrying out the proper "due diligence" responsibilities (see http://www.eclipse.org/legal/committerguidelines.php) so it needs to be a pretty focused list.
Now, to the task of the two individuals awaiting PMC approval in the Foundation Portal ... I suspect there's no way to simply "withdraw" the nominations and someone on the PMC should vote -1 (or, would zero work?) to close the loop and communicate to them these issues we've discussed. I'm new enough not to know what the "Tools PMC Protocol" is ... should the PMC Lead do it? Should we wait till after our meeting on the 25th?
Jeff McAffer ---02/21/2009 07:34:32 AM---I absolutely support the intention here and would actually like to have more people able/willing to
Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>
02/21/2009 07:34 AM
Re: [tools-pmc] PMC approval needed for committer vote for Kalin
I absolutely support the intention here and would actually like to have more people able/willing to manage bugs. But it seems there is some mechanical issue that is driving them to have to be "committers" when all that is really needed is a bit set in bugzilla saying they have more bug power. Put another way, we are using a hammer cause that's all we have.
Roy Ganor wrote:
Yes, I understand that I am the minority here J.
Although the Wikipedia definition (en.wikipedia.org/wiki/Committers) is just what Jeff was describing, I see no reason why Eclipse can’t extend this definition and embrace the ones who contribute and “commit” to its bug tracking “repository”. To eliminate the “use at your own risk” common notion in open source projects (in general), we should give the QA the power to do its work.
David, thank you for your support, I’ll be happy to assist you with the proposal.
From: tools-pmc-bounces@xxxxxxxxxxx [mailto:tools-pmc-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Thursday, February 19, 2009 4:32 PM
To: Tools PMC mailing list
Subject: Re: [tools-pmc] PMC approval needed for committer vote for Kalin
For me this is easy. Committers are people who need write access to the repos etc. I am all in favor of having help managing bugs and keeping that flowing. If there is an issue with how we can enable that, that is the issue to address.
David M Williams wrote:
Did we let this drop? Or, just rest a while? I'll take it upon myself to talk to Denis and come back with a proposal.
Well, these guys are very active testers who help a lot for the QA side of PDT 2.0 / PDT 2.1.
I asked Denis Roy specifically if there is a chance to give them permissions to Bugzilla (as testers) and he said no, you should nominate them as committers and give them permissions to Bugzilla only.
I missed this on first reading. Sounds like Denis was just suggesting the steps to follow to get "bugzilla committer rights" but without being a committer in the normal sense of the word. When the repository information was requested it'd be left blank or "bugzilla only" written in. And, in IP Logs, these "bugzilla committers" should not show up, since while they may have added to the quality of the project, they wouldn't have contributed Intellectual Property. In other words, sounds like we would have two camps of committers, with slightly different rules and implications ... and it'd sure make the infrastructure easier if the process was about the same.
So, I can imagine several outcomes ... some short term, some long term.
Please direct me what to do ...
In the short term, keep a flexible, open mind :)
I know on some projects I've worked on, people that wanted to verify or move bugs or assign priorities, etc., (which only committers can do) would simply write the information in bug entry, and route it to a committer to mark or correct in the database fields.
tools-pmc mailing list
tools-pmc mailing list
tools-pmc mailing list