geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Date Sun, 02 Jul 2006 06:15:34 GMT
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 <hiram@hiramchirino.com> 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
> > >>
> > >>
> > >
> > >
> >
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com

Mime
View raw message