geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jrsis...@gmail.com>
Subject Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Date Tue, 04 Jul 2006 23:54:24 GMT
Matt Hogstrom wrote:
> I do not believe the +1's need to be from PMC members but other 
> committers.  This is a snippet from Ken's personal web page:
>
> "Consequently, acting ex officio my VP/chair of Apache Geronimo role, 
> yesterday (Sunday, 21 May 2006) I changed the project's development 
> model from CTR (Commit-Then-Review) to RTC (Review-Then-Commit). This 
> means that all code changes that aren't to documentation or specific 
> bug fixes must be proposed to the development list as patches, and 
> three *[other] committers* need to verify them and vote in favour of 
> them before they can be applied to the code in the repository. (This 
> doesn't apply to the sandboxes and experimental areas, only the main 
> lines and branches of development.)"
>
> In Ken's original e-mail the vote required three other committers and 
> not specifically PMC members.  Here is the original e-mail.
>
> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/%3c4470FE4D.1090806@Golux.Com%3e

>
>
> It is my understanding that the an RTC request needs 3 other 
> committers to +1 it and does not require the other +1's to be PMC 
> members.
>
I understand that there has been confusion due to the original message 
from Ken mentioning committers in his original message, but Ken cleared 
this up in a message on the 18th of June (since his blog entry on the 
22nd May).

Please see  
http://www.mail-archive.com/dev@geronimo.apache.org/msg24899.html

Nobody should assume anything has changed from requiring 3 binding votes 
for RTC until they hear otherwise from Ken.

I encourage those not on the PMC to also vote on RTC requests as your 
input is valuable.

John
> Hiram Chirino 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 <jrsisson@gmail.com> 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
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>


Mime
View raw message