geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Date Wed, 05 Jul 2006 00:26:58 GMT

On Jul 4, 2006, at 4:54 PM, John Sisson wrote:

> 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 do not think that Ken is providing sufficient communication to the  
dev list.  As matt pointed out, the original edict to the dev list  
and ken's blog entry clearly and unequivocally stated that committer  
votes were binding for commit decisions.  Sometime later ken appears  
to have commmented on this policy with an interpretation that is  
radically different from the original very clear statement with an  
comment deep in a thread.  Personally I find that rather ambiguous.   
I think that if Ken has any interest in having clear rules that he  
has an obligation to clearly state changes to them either in the  
thread in which the rules are originally promulgated or in a separate  
thread but in any case clearly indicating what has changed.

Not to insult any pmc members, but it appears that this is an issue  
on which the PMC has absolutely no input.  As such, it is difficult  
for me to trust comments on this issue from anyone other than Ken.

thanks
david jencks

>
> 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