You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by John Sisson <jr...@gmail.com> on 2006/07/01 03:57:20 UTC
[Proposal] Tracking the status of patches under RTC (was Re: [RTC]
Clarification please from the PMC)
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)
* 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
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Ahh, a little bell went off in my head. When we were in CTR mode we
never really had code related votes, per se. That's why I don't recall
the committer/PMC duality w/ respect to code changes. I now realize how
RTC brings out this distinction.
Regards,
Alan
Aaron Mulder wrote:
> If the policy is that only PMC votes count for *everything*, then I
> think we should abolish the position of committer. Having a status of
> "allowed to commit bug fixes only" does not make sense to me.
>
> If we intend to return to CTR at some point, then committer probably
> makes sense, but I think we should be very explicit about for which
> votes only PMC members have binding opinions and for which (if any)
> votes committer opinions are binding. I feel like I was not at all
> clear on the authority of PMC and the PMC chair. Did anything related
> to this come out of the docathon?
>
> Thanks,
> Aaron
>
> On 7/2/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> Jacek Laskowski wrote:
>> > On 7/2/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> >> Please read Ken's original email:
>> >>
>> >>
>> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/%3c4470FE4D.1090806@Golux.Com%3e
>>
>> >>
>> >>
>> >> As far as not considering commiters votes binding, this has never
>> been
>> >> the way Geronimo was run. If things have changed and the PMC has
>> >> decided that this is the new way to go, ok. But let there be no
>> >> confusion as to the way things used to work.
>> >
>> > What about this:
>> > http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html?
>>
>> A comment in the middle of a long and arduous thread. Not quite an
>> official notice that Ken and/or the PMC have changed their mind from
>> what was stated during the official announcement of the change to RTC
>> sent out the previous month.
>>
>> > As far as binding votes go it's never been such a distinction between
>> > people heavily involved in Geronimo development and PMCers. We were
>> > pretty close to PMCers == committers and I don't remember a situation
>> > where -1 was issued. There were enough +1's from PMCers. Therefore,
>> > *I* would say it's almost impossible to compare what's happening now
>> > with what was in the past. The situation is new and uncomparable to
>> > anything as far as I understand it (and thus there're so many
>> > misunderstandings and discussion about what RTC really means).
>>
>> So are you saying that it was your understanding that, all along during
>> the history of Geronimo, commiters votes never mattered? I honestly
>> don't recall us making that distinction, ever.
>>
>> IMHO, there is no misunderstanding to what RTC means now; it means 3 +1
>> PMC votes. There is confusion not because we had been operating along
>> the lines of PMC votes only count for matters of code and now the
>> committee make up has changed. There is confusion because Ken's
>> official announcement said 3 +1 committer votes.
>>
>> >> Please confirm that this is the new way that the PMC has decided
>> to run
>> >> things.
>> >
>> > It's never changed - only PMC votes are binding as outlined in
>> > http://www.apache.org/foundation/voting.html, but I myself consider
>> > any vote binding as far as changes are concerned. A release is a legal
>> > stuff so it requires a special attention from ASF itself and thus the
>> > requirement about PMCers and their binding votes.
>>
>> Jacek, I understand what the HTML page says. I am not arguing against
>> what it says nor am I arguing against the value of such a position. I
>> am one of the founding members of Geronimo and I don't recall that we
>> ever made a distinction between commiters and PMC members when it came
>> to what gets checked into the code base.
>>
>> If you guys want to change the way we've been previously working, more
>> specifically in regards to RTC, then fine. Let's do it. But don't
>> pretend that we all have been operating that way all along because we
>> have not.
>>
>>
>> Regards,
>> Alan
>>
>>
>>
Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
If the policy is that only PMC votes count for *everything*, then I
think we should abolish the position of committer. Having a status of
"allowed to commit bug fixes only" does not make sense to me.
If we intend to return to CTR at some point, then committer probably
makes sense, but I think we should be very explicit about for which
votes only PMC members have binding opinions and for which (if any)
votes committer opinions are binding. I feel like I was not at all
clear on the authority of PMC and the PMC chair. Did anything related
to this come out of the docathon?
Thanks,
Aaron
On 7/2/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Jacek Laskowski wrote:
> > On 7/2/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> >> Please read Ken's original email:
> >>
> >> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/%3c4470FE4D.1090806@Golux.Com%3e
> >>
> >>
> >> As far as not considering commiters votes binding, this has never been
> >> the way Geronimo was run. If things have changed and the PMC has
> >> decided that this is the new way to go, ok. But let there be no
> >> confusion as to the way things used to work.
> >
> > What about this:
> > http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html?
>
> A comment in the middle of a long and arduous thread. Not quite an
> official notice that Ken and/or the PMC have changed their mind from
> what was stated during the official announcement of the change to RTC
> sent out the previous month.
>
> > As far as binding votes go it's never been such a distinction between
> > people heavily involved in Geronimo development and PMCers. We were
> > pretty close to PMCers == committers and I don't remember a situation
> > where -1 was issued. There were enough +1's from PMCers. Therefore,
> > *I* would say it's almost impossible to compare what's happening now
> > with what was in the past. The situation is new and uncomparable to
> > anything as far as I understand it (and thus there're so many
> > misunderstandings and discussion about what RTC really means).
>
> So are you saying that it was your understanding that, all along during
> the history of Geronimo, commiters votes never mattered? I honestly
> don't recall us making that distinction, ever.
>
> IMHO, there is no misunderstanding to what RTC means now; it means 3 +1
> PMC votes. There is confusion not because we had been operating along
> the lines of PMC votes only count for matters of code and now the
> committee make up has changed. There is confusion because Ken's
> official announcement said 3 +1 committer votes.
>
> >> Please confirm that this is the new way that the PMC has decided to run
> >> things.
> >
> > It's never changed - only PMC votes are binding as outlined in
> > http://www.apache.org/foundation/voting.html, but I myself consider
> > any vote binding as far as changes are concerned. A release is a legal
> > stuff so it requires a special attention from ASF itself and thus the
> > requirement about PMCers and their binding votes.
>
> Jacek, I understand what the HTML page says. I am not arguing against
> what it says nor am I arguing against the value of such a position. I
> am one of the founding members of Geronimo and I don't recall that we
> ever made a distinction between commiters and PMC members when it came
> to what gets checked into the code base.
>
> If you guys want to change the way we've been previously working, more
> specifically in regards to RTC, then fine. Let's do it. But don't
> pretend that we all have been operating that way all along because we
> have not.
>
>
> Regards,
> Alan
>
>
>
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jacek Laskowski wrote:
> On 7/2/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> Please read Ken's original email:
>>
>> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/%3c4470FE4D.1090806@Golux.Com%3e
>>
>>
>> As far as not considering commiters votes binding, this has never been
>> the way Geronimo was run. If things have changed and the PMC has
>> decided that this is the new way to go, ok. But let there be no
>> confusion as to the way things used to work.
>
> What about this:
> http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html?
A comment in the middle of a long and arduous thread. Not quite an
official notice that Ken and/or the PMC have changed their mind from
what was stated during the official announcement of the change to RTC
sent out the previous month.
> As far as binding votes go it's never been such a distinction between
> people heavily involved in Geronimo development and PMCers. We were
> pretty close to PMCers == committers and I don't remember a situation
> where -1 was issued. There were enough +1's from PMCers. Therefore,
> *I* would say it's almost impossible to compare what's happening now
> with what was in the past. The situation is new and uncomparable to
> anything as far as I understand it (and thus there're so many
> misunderstandings and discussion about what RTC really means).
So are you saying that it was your understanding that, all along during
the history of Geronimo, commiters votes never mattered? I honestly
don't recall us making that distinction, ever.
IMHO, there is no misunderstanding to what RTC means now; it means 3 +1
PMC votes. There is confusion not because we had been operating along
the lines of PMC votes only count for matters of code and now the
committee make up has changed. There is confusion because Ken's
official announcement said 3 +1 committer votes.
>> Please confirm that this is the new way that the PMC has decided to run
>> things.
>
> It's never changed - only PMC votes are binding as outlined in
> http://www.apache.org/foundation/voting.html, but I myself consider
> any vote binding as far as changes are concerned. A release is a legal
> stuff so it requires a special attention from ASF itself and thus the
> requirement about PMCers and their binding votes.
Jacek, I understand what the HTML page says. I am not arguing against
what it says nor am I arguing against the value of such a position. I
am one of the founding members of Geronimo and I don't recall that we
ever made a distinction between commiters and PMC members when it came
to what gets checked into the code base.
If you guys want to change the way we've been previously working, more
specifically in regards to RTC, then fine. Let's do it. But don't
pretend that we all have been operating that way all along because we
have not.
Regards,
Alan
Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/2/06, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Please read Ken's original email:
>
> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/%3c4470FE4D.1090806@Golux.Com%3e
>
> As far as not considering commiters votes binding, this has never been
> the way Geronimo was run. If things have changed and the PMC has
> decided that this is the new way to go, ok. But let there be no
> confusion as to the way things used to work.
What about this:
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html?
As far as binding votes go it's never been such a distinction between
people heavily involved in Geronimo development and PMCers. We were
pretty close to PMCers == committers and I don't remember a situation
where -1 was issued. There were enough +1's from PMCers. Therefore,
*I* would say it's almost impossible to compare what's happening now
with what was in the past. The situation is new and uncomparable to
anything as far as I understand it (and thus there're so many
misunderstandings and discussion about what RTC really means).
> Please confirm that this is the new way that the PMC has decided to run
> things.
It's never changed - only PMC votes are binding as outlined in
http://www.apache.org/foundation/voting.html, but I myself consider
any vote binding as far as changes are concerned. A release is a legal
stuff so it requires a special attention from ASF itself and thus the
requirement about PMCers and their binding votes.
> Alan
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Please read Ken's original email:
http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/%3c4470FE4D.1090806@Golux.Com%3e
As far as not considering commiters votes binding, this has never been
the way Geronimo was run. If things have changed and the PMC has
decided that this is the new way to go, ok. But let there be no
confusion as to the way things used to work.
Please confirm that this is the new way that the PMC has decided to run
things.
Regards,
Alan
John Sisson 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
>>>
>>>
>>
>>
>
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by John Sisson <jr...@gmail.com>.
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
>>
>>
>
>
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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)
> * 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
>
>
Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Posted by Jason Dillon <ja...@planet57.com>.
>> GERONIMO-1234-FixNPE-v1
>> GERONIMO-1234-FixNPE-v2 (second attempt at patch)
>> GERONIMO-3421-v1
>>
> Why should a patch that has been attached to a specific Jira issue
> include the number of the jira issue? I don't mind but it seems
> odd and usually that means that I am misunderstanding something.
I like to have the JIRA id as part of the filename so it is clear
what it is when I download it to inspect/apply.
--jason
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by John Sisson <jr...@gmail.com>.
Alan D. Cabrera wrote:
> John Sisson wrote:
>> Alan D. Cabrera wrote:
>>> John Sisson wrote:
>>>> Alan D. Cabrera wrote:
>>>>> John Sisson wrote:
>>>>>> Alan D. Cabrera wrote:
>>>>>>>
>>>>>>>
>>>>>>> John Sisson wrote:
>>>>>>> <snip>
>>>>>>> Lots of process...
>>>>>>> </snip>
>>>>>>>
>>>>>>>>>> * 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".
>>>>>>>>> Just need to move it on to the regular Open status, no?
>>>>>>>> Thought it may be clearer to have a different status showing
>>>>>>>> the review is complete and have the JIRA workflow match the
>>>>>>>> true workflow. For example if we were to move to open status
>>>>>>>> after the review is complete, then the user would be given the
>>>>>>>> opportunity to go back to review-required status, which isn't
>>>>>>>> really a valid state transition, but maybe we should keep it
>>>>>>>> simple and rely upon common sense? Any JIRA experts out there
>>>>>>>> who can comment on the benefits/disadvantages of having an
>>>>>>>> additional review-complete status?
>>>>>>> mmm, ok. I'm sold.
>>>>>>>
>>>>>>> I'm a Jira admin so I have dug up the work flow that we're
>>>>>>> currently using. Here's what I think we're proposing.
>>>> Thanks for creating the diagrams Alan.
>>>>
>>>> Currently one can create "Open" a JIRA issue and start working on
>>>> it, optionally marking it as "In Progress" as you showed below in
>>>> your first diagram. In your second diagram this won't be
>>>> possible. The JIRA should be able to be worked on prior to RTC
>>>> (and hopefully will be discussed on the dev list with the developer
>>>> community before it gets to the RTC phase).
>>>
>>> Ok, so the "In Progress" state will go off of Open state. I guess
>>> that the idea of the reviewed state for the actual patch
>>> application. Please note that I have removed the Reopened state.
>>> It seemed superfluous.
>>>
>>>> A JIRA issue may also be created for a bug and bug fixes do not
>>>> need to go through the RTC process.
>>>
>>> Yeah, we can use the current process for that.
>>>
>>>> I assume we would always allow the user to move to the Review state
>>>> (no matter what their issue type is) rather than trying to restrict
>>>> it programatically.
>>>
>>> I had intended to restrict it. Do you think that it would be useful
>>> to always be able to move back to a RTC voting stage? When would we
>>> need to do that after approval?
>> How did you intend to restrict it?
>
> By just simply limiting the transitions. Anything else would require
> us dropping a plugin into the Jira server.
>
>> There is a possibility that that the developer of the patch or
>> another developer could discover an issue with the patch after it has
>> been approved but before it was committed and wants to revise the
>> patch and go through the review again. Should we allow transitions
>> from the review and reviewed states to the Open state to cater for
>> this type of situation (it may take the developer a couple of weeks
>> to rework the patch before they
>
> Ok, so every state should have a transition to go back to Open?
>
I think that would allow the most flexibility.
Thanks,
John
>
> Regards,
> Alan
>
>
>
>
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
John Sisson wrote:
> Alan D. Cabrera wrote:
>> John Sisson wrote:
>>> Alan D. Cabrera wrote:
>>>> John Sisson wrote:
>>>>> Alan D. Cabrera wrote:
>>>>>>
>>>>>>
>>>>>> John Sisson wrote:
>>>>>> <snip>
>>>>>> Lots of process...
>>>>>> </snip>
>>>>>>
>>>>>>>>> * 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".
>>>>>>>> Just need to move it on to the regular Open status, no?
>>>>>>> Thought it may be clearer to have a different status showing the
>>>>>>> review is complete and have the JIRA workflow match the true
>>>>>>> workflow. For example if we were to move to open status after
>>>>>>> the review is complete, then the user would be given the
>>>>>>> opportunity to go back to review-required status, which isn't
>>>>>>> really a valid state transition, but maybe we should keep it
>>>>>>> simple and rely upon common sense? Any JIRA experts out there
>>>>>>> who can comment on the benefits/disadvantages of having an
>>>>>>> additional review-complete status?
>>>>>> mmm, ok. I'm sold.
>>>>>>
>>>>>> I'm a Jira admin so I have dug up the work flow that we're
>>>>>> currently using. Here's what I think we're proposing.
>>> Thanks for creating the diagrams Alan.
>>>
>>> Currently one can create "Open" a JIRA issue and start working on
>>> it, optionally marking it as "In Progress" as you showed below in
>>> your first diagram. In your second diagram this won't be possible.
>>> The JIRA should be able to be worked on prior to RTC (and hopefully
>>> will be discussed on the dev list with the developer community
>>> before it gets to the RTC phase).
>>
>> Ok, so the "In Progress" state will go off of Open state. I guess
>> that the idea of the reviewed state for the actual patch
>> application. Please note that I have removed the Reopened state. It
>> seemed superfluous.
>>
>>> A JIRA issue may also be created for a bug and bug fixes do not need
>>> to go through the RTC process.
>>
>> Yeah, we can use the current process for that.
>>
>>> I assume we would always allow the user to move to the Review state
>>> (no matter what their issue type is) rather than trying to restrict
>>> it programatically.
>>
>> I had intended to restrict it. Do you think that it would be useful
>> to always be able to move back to a RTC voting stage? When would we
>> need to do that after approval?
> How did you intend to restrict it?
By just simply limiting the transitions. Anything else would require us
dropping a plugin into the Jira server.
> There is a possibility that that the developer of the patch or another
> developer could discover an issue with the patch after it has been
> approved but before it was committed and wants to revise the patch and
> go through the review again. Should we allow transitions from the
> review and reviewed states to the Open state to cater for this type of
> situation (it may take the developer a couple of weeks to rework the
> patch before they
Ok, so every state should have a transition to go back to Open?
Regards,
Alan
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by John Sisson <jr...@gmail.com>.
Alan D. Cabrera wrote:
> John Sisson wrote:
>> Alan D. Cabrera wrote:
>>> John Sisson wrote:
>>>> Alan D. Cabrera wrote:
>>>>>
>>>>>
>>>>> John Sisson wrote:
>>>>> <snip>
>>>>> Lots of process...
>>>>> </snip>
>>>>>
>>>>>>>> * 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".
>>>>>>> Just need to move it on to the regular Open status, no?
>>>>>> Thought it may be clearer to have a different status showing the
>>>>>> review is complete and have the JIRA workflow match the true
>>>>>> workflow. For example if we were to move to open status after
>>>>>> the review is complete, then the user would be given the
>>>>>> opportunity to go back to review-required status, which isn't
>>>>>> really a valid state transition, but maybe we should keep it
>>>>>> simple and rely upon common sense? Any JIRA experts out there
>>>>>> who can comment on the benefits/disadvantages of having an
>>>>>> additional review-complete status?
>>>>> mmm, ok. I'm sold.
>>>>>
>>>>> I'm a Jira admin so I have dug up the work flow that we're
>>>>> currently using. Here's what I think we're proposing.
>> Thanks for creating the diagrams Alan.
>>
>> Currently one can create "Open" a JIRA issue and start working on it,
>> optionally marking it as "In Progress" as you showed below in your
>> first diagram. In your second diagram this won't be possible. The
>> JIRA should be able to be worked on prior to RTC (and hopefully will
>> be discussed on the dev list with the developer community before it
>> gets to the RTC phase).
>
> Ok, so the "In Progress" state will go off of Open state. I guess
> that the idea of the reviewed state for the actual patch application.
> Please note that I have removed the Reopened state. It seemed
> superfluous.
>
>> A JIRA issue may also be created for a bug and bug fixes do not need
>> to go through the RTC process.
>
> Yeah, we can use the current process for that.
>
>> I assume we would always allow the user to move to the Review state
>> (no matter what their issue type is) rather than trying to restrict
>> it programatically.
>
> I had intended to restrict it. Do you think that it would be useful
> to always be able to move back to a RTC voting stage? When would we
> need to do that after approval?
How did you intend to restrict it?
There is a possibility that that the developer of the patch or another
developer could discover an issue with the patch after it has been
approved but before it was committed and wants to revise the patch and
go through the review again. Should we allow transitions from the
review and reviewed states to the Open state to cater for this type of
situation (it may take the developer a couple of weeks to rework the
patch before they want it reviewed again, so won't want it showing up in
the RTC reports)?
Thanks,
John
>
>
> Regards,
> Alan
>
>
>
> ------------------------------------------------------------------------
>
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
John Sisson wrote:
> Alan D. Cabrera wrote:
>> John Sisson wrote:
>>> Alan D. Cabrera wrote:
>>>>
>>>>
>>>> John Sisson wrote:
>>>> <snip>
>>>> Lots of process...
>>>> </snip>
>>>>
>>>>>>> * 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".
>>>>>> Just need to move it on to the regular Open status, no?
>>>>> Thought it may be clearer to have a different status showing the
>>>>> review is complete and have the JIRA workflow match the true
>>>>> workflow. For example if we were to move to open status after the
>>>>> review is complete, then the user would be given the opportunity
>>>>> to go back to review-required status, which isn't really a valid
>>>>> state transition, but maybe we should keep it simple and rely upon
>>>>> common sense? Any JIRA experts out there who can comment on the
>>>>> benefits/disadvantages of having an additional review-complete
>>>>> status?
>>>> mmm, ok. I'm sold.
>>>>
>>>> I'm a Jira admin so I have dug up the work flow that we're
>>>> currently using. Here's what I think we're proposing.
> Thanks for creating the diagrams Alan.
>
> Currently one can create "Open" a JIRA issue and start working on it,
> optionally marking it as "In Progress" as you showed below in your
> first diagram. In your second diagram this won't be possible. The
> JIRA should be able to be worked on prior to RTC (and hopefully will
> be discussed on the dev list with the developer community before it
> gets to the RTC phase).
Ok, so the "In Progress" state will go off of Open state. I guess that
the idea of the reviewed state for the actual patch application. Please
note that I have removed the Reopened state. It seemed superfluous.
> A JIRA issue may also be created for a bug and bug fixes do not need
> to go through the RTC process.
Yeah, we can use the current process for that.
> I assume we would always allow the user to move to the Review state
> (no matter what their issue type is) rather than trying to restrict it
> programatically.
I had intended to restrict it. Do you think that it would be useful to
always be able to move back to a RTC voting stage? When would we need
to do that after approval?
Regards,
Alan
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by John Sisson <jr...@gmail.com>.
Alan D. Cabrera wrote:
> John Sisson wrote:
>> Alan D. Cabrera wrote:
>>>
>>>
>>> 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.
>>> I think that we only need a Review status. But, in any case, Jira
>>> is definitely the way to go.
>>>>
>>>> 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
>>>>
>>> Why should a patch that has been attached to a specific Jira issue
>>> include the number of the jira issue? I don't mind but it seems odd
>>> and usually that means that I am misunderstanding something.
>> I was just trying to make it simpler for people so there is no
>> confusion with what patch file they are working with once they save
>> the patch to their PC from the JIRA issue.
>
> Cool, makes sense, but let's not make it a hard and fast rule.
>
>>>> 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.
>>> There should be a way to enforce it.
>>>>
>>>>
>
> <snip>
> Lots of process...
> </snip>
>
>>>> * 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".
>>> Just need to move it on to the regular Open status, no?
>> Thought it may be clearer to have a different status showing the
>> review is complete and have the JIRA workflow match the true
>> workflow. For example if we were to move to open status after the
>> review is complete, then the user would be given the opportunity to
>> go back to review-required status, which isn't really a valid state
>> transition, but maybe we should keep it simple and rely upon common
>> sense? Any JIRA experts out there who can comment on the
>> benefits/disadvantages of having an additional review-complete status?
> mmm, ok. I'm sold.
>
> I'm a Jira admin so I have dug up the work flow that we're currently
> using. Here's what I think we're proposing.
>
>
> Regards,
> Alan
>
>
>
Thanks for creating the diagrams Alan.
Currently one can create "Open" a JIRA issue and start working on it,
optionally marking it as "In Progress" as you showed below in your first
diagram. In your second diagram this won't be possible. The JIRA
should be able to be worked on prior to RTC (and hopefully will be
discussed on the dev list with the developer community before it gets to
the RTC phase).
A JIRA issue may also be created for a bug and bug fixes do not need to
go through the RTC process.
I assume we would always allow the user to move to the Review state (no
matter what their issue type is) rather than trying to restrict it
programatically.
Thanks,
John
>
>
>
>
> ------------------------------------------------------------------------
>
Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Posted by Jason Dillon <ja...@planet57.com>.
This looks very reasonable.
--jason
> I'm a Jira admin so I have dug up the work flow that we're
> currently using. Here's what I think we're proposing.
>
>
> Regards,
> Alan
>
>
>
>
>
>
> <Jira-State.gnp>
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
John Sisson wrote:
> Alan D. Cabrera wrote:
>>
>>
>> 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.
>> I think that we only need a Review status. But, in any case, Jira is
>> definitely the way to go.
>>>
>>> 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
>>>
>> Why should a patch that has been attached to a specific Jira issue
>> include the number of the jira issue? I don't mind but it seems odd
>> and usually that means that I am misunderstanding something.
> I was just trying to make it simpler for people so there is no
> confusion with what patch file they are working with once they save
> the patch to their PC from the JIRA issue.
Cool, makes sense, but let's not make it a hard and fast rule.
>>> 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.
>> There should be a way to enforce it.
>>>
>>>
<snip>
Lots of process...
</snip>
>>> * 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".
>> Just need to move it on to the regular Open status, no?
> Thought it may be clearer to have a different status showing the
> review is complete and have the JIRA workflow match the true
> workflow. For example if we were to move to open status after the
> review is complete, then the user would be given the opportunity to go
> back to review-required status, which isn't really a valid state
> transition, but maybe we should keep it simple and rely upon common
> sense? Any JIRA experts out there who can comment on the
> benefits/disadvantages of having an additional review-complete status?
mmm, ok. I'm sold.
I'm a Jira admin so I have dug up the work flow that we're currently
using. Here's what I think we're proposing.
Regards,
Alan
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by John Sisson <jr...@gmail.com>.
Alan D. Cabrera wrote:
>
>
> 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.
> I think that we only need a Review status. But, in any case, Jira is
> definitely the way to go.
>>
>> 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
>>
> Why should a patch that has been attached to a specific Jira issue
> include the number of the jira issue? I don't mind but it seems odd
> and usually that means that I am misunderstanding something.
I was just trying to make it simpler for people so there is no confusion
with what patch file they are working with once they save the patch to
their PC from the JIRA issue.
>> 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.
> There should be a way to enforce it.
>>
>> 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)
>> * 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".
> Just need to move it on to the regular Open status, no?
Thought it may be clearer to have a different status showing the review
is complete and have the JIRA workflow match the true workflow. For
example if we were to move to open status after the review is complete,
then the user would be given the opportunity to go back to
review-required status, which isn't really a valid state transition, but
maybe we should keep it simple and rely upon common sense? Any JIRA
experts out there who can comment on the benefits/disadvantages of
having an additional review-complete status?
John
>>
>> 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 .
>>
>
> This stuff sounds pretty cool.
>
>
> Regards,
> Alan
>
>
>
Re: [Proposal] Tracking the status of patches under RTC (was Re:
[RTC] Clarification please from the PMC)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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.
I think that we only need a Review status. But, in any case, Jira is
definitely the way to go.
>
> 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
>
Why should a patch that has been attached to a specific Jira issue
include the number of the jira issue? I don't mind but it seems odd and
usually that means that I am misunderstanding something.
> 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.
There should be a way to enforce it.
>
> 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)
> * 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".
Just need to move it on to the regular Open status, no?
>
> 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 .
>
This stuff sounds pretty cool.
Regards,
Alan
Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
Posted by Jason Dillon <ja...@planet57.com>.
> 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 ).
-0, I'd rather not...
> 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.
+1, this is a good use of JIRA.
> 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.
Well, I guess it depends on how permanent the RTC rules are... making
changes to use additional statues means modification of the project's
workflow. Unfortunately changing the workflow in JIRA is not a
trivial task, and will have large affects over all issues in the
project. For example, if we introduce new statues, then remove them
later, the state of the issues associated with those states is lost.
But if we do want new statues... there are already these statues in
JIRA (used by Derby):
* Patch Available
* Patch Reviewed
* Patch Revised
* Patch Finalized
If this is going to be more temporary in nature, then it might make
more sense to create a new JIRA project to hold these issues and
workflow configuration, which would leave the other projects unchanged.
We'd probably have to create a new project anyways to setup and test
the configuration, since to validate and apply the workflow it must
be attached to the project... but when attached it can not be edited,
so you have to keep attaching and detaching the workflow to get
things modified.
And in the end we may end up wanting to keep this new project around
to help manage votes/reviews on other stuff too.
* * *
On the other-hand... it is much easier to add a new field to a
project, which can be a combo list which could be something like:
Review Status:
* Required
* Accepted
* Rejected
> 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
This is generally a good idea, RTC or not.
> 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.
JIRA can enforce this... BUT, not very easily. Using the workflow
impl it is possible to only allow members of a group to trigger the
transition... not sure if the version of JIRA that the ASF is running
can do this though.
We can always write a plugin to implement the behavior we want, but
this is also troublesome as it will require getting ASF Infra
involved to reconfigure and redeploy JIRA with our plugin.
IMO, while it is possible to get the tool to do this, it is much less
painful to just make the management of setting these states to be a
human process. It would be nice if JIRA was more friendly at helping
to implement this type of functionality though...
> 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.
Should be able to control this by groups and screens (depending on if
a status or field).
> I would be interested in your comments Jason, as you are more
> familiar with customizing JIRA.
IMO, using the workflow is probably the right way to implement
this... but harder. Custom field is easier... but less than ideal.
I recommend we create a new JIRA project, configure that projects
workflow to implement the procedure and then see how well it works
out. As I mentioned before, this project could also be used to track
other non-RTC voting too.
Come to think of it... we might even want to introduce a new Issue
type for RTC and/or Vote.
> 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 .
I think that it is a good idea to have a page like Derby does to
provide bug/issue guide-lines.
--jason