I think we have been operation under a different assumption. I know I committed a patch when 1 got 3 committer +1s... And not even 1 PMC member looked at it. And that took over a week to garner enough votes. Imagine how long it would take if we had to get 3 PMC +1! I think we need to clear this up ASAP!
On 7/1/06, John Sisson <[EMAIL PROTECTED]> wrote:
AFAIK, it has never changed from having three binding +1 votes from the
PMC, which is why there is an issue with a bottleneck processing RTCs
due to the size of the PMC.
It may not have been clearly communicated that that is how RTC works.
See Ken's comment in
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html
Also see http://www.apache.org/foundation/voting.html where it says
"Only votes by PMC members are considered binding on code-modification
issues".
Made change below...
John
Alan D. Cabrera wrote:
> I don't understand how things changed from an RTC needing three +1
> votes from other committers to three +1 votes from a PMC member. Did
> I miss an email that got sent out from the PMC?
>
>
> Regards,
> Alan
>
> John Sisson wrote:
>> One of the issues I see with the current process we have for changes
>> under RTC is that it is hard to keep track of what patches are
>> pending RTC.
>>
>> Ken suggested that we reintroduce the STATUS file as a way of keeping
>> track of the status of patches (
>> http://www.mail-archive.com/dev%40geronimo.apache.org/msg24780.html ).
>> On the same thread, Dain suggested introducing a "review-required"
>> status in JIRA (
>> http://www.mail-archive.com/dev%40geronimo.apache.org/msg25122.html )
>> and is the method of tracking work that I prefer.
>>
>> PROPOSAL
>>
>> 1. Add a "review-required" and "review-complete" statuses to JIRA. I
>> thought having two statuses might allow a cleaner workflow in JIRA,
>> but would be interested in hearing others opinions.
>>
>> 2. To make it easy for those reviewing and voting on the patches
>> (there could end up being a number of revisions of the patch before
>> it is accepted) the file names of the patches attached to the JIRA
>> should be prefixed with the JIRA issue identifier followed by an
>> optional text followed by a mandatory patch version number (starting
>> at 1).
>> Example patch names:
>>
>> GERONIMO-1234-FixNPE-v1
>> GERONIMO-1234-FixNPE-v2 (second attempt at patch)
>> GERONIMO-3421-v1
>>
>> 2.1 This status should only be set by a committer (can we can get
>> JIRA to enforce this?) when they have tested the patch attached to
>> the JIRA and believe it is ready for review. 2.2 The JIRA should
>> contain all information about the patch. If the changes were
>> previously discussed on the dev list prior to the JIRA being created,
>> a summary of the discussions should be moved into the JIRA so that
>> those reviewing the patch have all the information in one place. It
>> would also be preferable to add links to the original discussions on
>> the dev list archives. The way we document changes may be subject
>> to change (e.g. detailed documentation placed in a linked JIRA) based
>> upon the outcome of the discussions in the thread "[DISCUSS] Tracking
>> documentation tasks in JIRA ( was Re: [RTC] Clarification please from
>> the PMC )"
>>
>> 2.3 Each PMC member who reviews the patch attached to the JIRA must
>> do the following:
>> * Add a JIRA comment containing the file name of the patch they
>> reviewed. This is so there is no confusion if there ends up being
>> multiple revisions of the patch when collating votes.
>> * In the JIRA comment add the results of their review (e.g.
>> comments or a vote). If a PMC member vetos the patch, they must
>> include a technical justification in their JIRA comments. I propose
>> that when there is a veto that we leave the status as
>> "review-required", as others may still want to vote and so that the
>> patch remains getting daily visibility in the "JIRAs Pending Review"
>> daily email (proposed below). The committer can then re-submit
>> another patch (where the patch filename has the version number bumped
>> up)
A committer could veto, but it wouldn't be binding, so the above
paragraph should probably be changed to:
* In the JIRA comment add the results of their review ( e.g. comments or
a vote). If a committer vetos the patch (note that only PMC votes are
binding), they must include a technical justification in their JIRA
comments. I propose that when there is a veto that we leave the status
as "review-required", as others may still want to vote and so that the
patch remains getting daily visibility in the "JIRAs Pending Review"
daily email (proposed below). The committer can then re-submit another
patch (where the patch filename has the version number bumped up)
>> * If a PMC member is the person who completes the vote ( three
>> binding +1s and no vetos) for the latest version of the patch then
>> they should change the status to "review-complete".
>>
>> 3. Non-committers who submit patches will not be able to set this
>> status. A committer needs to pick up their patch and test it
>> (possibly making changes to the patch). When the patch is ready the
>> committer then sets the "review-required" status.
>>
>> 4. Have a daily email automatically sent to the dev list containing
>> JIRA's pending review. It appears this should be easy to implement
>> as it would be a variation of the weekly "Unassigned Patches" reports
>> that are currently in place.
>> I would be interested in your comments Jason, as you are more
>> familiar with customizing JIRA.
>>
>> If this proposal is accepted I will document it as part of the work I
>> plan to do to document the use of JIRA in
>> http://issues.apache.org/jira/browse/GERONIMO-2080 .
>>
>> John
>>
>>
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
