Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
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)
Please read Ken's original email: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL PROTECTED] 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
Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
On 7/2/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Please read Ken's original email: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL PROTECTED] 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)
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)
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)
Jacek Laskowski wrote: On 7/2/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Please read Ken's original email: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL PROTECTED] 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)
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 [EMAIL PROTECTED] wrote: Jacek Laskowski wrote: On 7/2/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Please read Ken's original email: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL PROTECTED] 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)
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 [EMAIL PROTECTED] wrote: Jacek Laskowski wrote: On 7/2/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Please read Ken's original email: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL PROTECTED] 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)
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)
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)
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)
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)
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)
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
Re: [Proposal] Tracking the status of patches under RTC (was Re: [RTC] Clarification please from the PMC)
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
[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
