If the PMC interpretation stands, does that mean the only privileges of a committer who's not on the PMC are to commit bug fixes?
Thanks, Aaron On 7/2/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
Whoa! 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
