geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Date Sun, 02 Jul 2006 04:51:31 GMT
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
> >>
> >>
> >
> >
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message