atom feed17 messages in org.apache.maven.devhow we handle JIRA versions
FromSent OnAttachments
Brett PorterAug 1, 2007 9:47 am 
Dennis LundbergAug 1, 2007 12:31 pm 
Brett PorterAug 1, 2007 7:00 pm 
Jason van ZylAug 1, 2007 8:21 pm 
Christian GruberAug 1, 2007 8:25 pm 
Brett PorterAug 1, 2007 8:37 pm 
Jason van ZylAug 1, 2007 8:51 pm 
Brett PorterAug 1, 2007 8:55 pm 
Brian E. FoxAug 1, 2007 9:01 pm 
Brett PorterAug 1, 2007 11:11 pm 
jaso...@gmail.comAug 1, 2007 11:24 pm 
Brett PorterAug 1, 2007 11:37 pm 
Dennis LundbergAug 2, 2007 3:11 am 
Dennis LundbergAug 2, 2007 3:20 am 
Jason DillonAug 2, 2007 3:28 am 
Brett PorterAug 2, 2007 3:29 am 
Vincent SivetonSep 12, 2007 3:54 pm 
Subject:how we handle JIRA versions
From:Brett Porter (bre@apache.org)
Date:Aug 1, 2007 9:47:44 am
List:org.apache.maven.dev

Hi,

A while back I promised to write up what we are doing with jira versions now, and finally got around to it. In the process, I came up with a couple of tweaks we could make (see "actions"). Here it is in point form - does everyone agree this is the process we are following now? Missing anything?

- [ ] versions: - [ ] 2.0.8 - the next release, currently being worked on for the 2.0.x branch - [ ] 2.0.x - issues that are likely to be fixed in the 2.0.x series, but not yet scheduled - [ ] 2.1-alpha-1 - the next release, currently being worked on for trunk - [ ] 2.1-alpha-2 - the release after next, and so on - [ ] 2.1 - issues to fix by the 2.1 final release - [ ] 2.1.x - issues to list as "known issues" in 2.1, and to be fixed in the releases after 2.1. - [ ] 2.2 - issues to fix in the 2.2 release (not yet broken down as it is a future release) - [ ] 2.x - issues to fix in later 2.x releases (not yet scheduled) - [ ] Backlog - issues that have not been reviewed for a version assignment (and may be duplicates, won't fix, unreproducible, etc.) - [ ] Unscheduled - new issues that haven't been reviewed yet - [ ] actions - [ ] rename 2.1.x to 2.1 - [ ] create 2.1.x after 2.1 - [ ] rename 2.2.x to 2.2 - [ ] create 2.x - [ ] take a knife to 2.1 (currently 2.1.x) which has 254 issues - [ ] rename "Reviewed Pending Version Assignment" to "Backlog" - [ ] move all documentation issues either to the site project (this should all be done by now), or to a scheduled version (or the backlog) - [ ] create a shared jira and move the shared component issues to that. - [ ] workflow - [ ] for a new issue in unscheduled - [ ] should attempt to review them quickly and regularly - [ ] first action is to attempt to resolve reasonably (duplicate, won't fix if it's inappropriate, or incomplete if there is not enough detail) - [ ] double check priority and other details like affects version and component and prompt for more information if needed - [ ] all issues should have an affects version(s) and component(s) - [ ] assign a version depending on whether it's a bug or a feature, and what it's severity is - [ ] unless it is a regression in the current code, it should not be assigned to the current version - [ ] for an issue in backlog - [ ] periodically review issues related to other ongoing work to attempt to close duplicates or assign to an appropriate version - [ ] for an issue in the current release that could be bumped - [ ] should not be done if it's a blocker or a regression - [ ] can be done en masse for remaining issues when a release is called based on an agreed date and nothing left in scheduled features/blockers/regressions list - [ ] can be done for individual issues earlier than that if time runs short or priority becomes reduced - [ ] planning for the next release - [ ] during the previous release or after it's complete, planning for the next one should occur - [ ] should reasonably prevent adding new issues to a release once it becomes the current one (unless the issue is a blocker or regression) - [ ] create a new version and pull back from the generic bucket (for 2.1-alpha-2, these are taken from 2.1, for 2.0.8 they are taken from 2.0.x, for 2.1's first cut they are taken from 2.x). - [ ] use votes, priorities and effort/relatedness to other issues to determine which issues to schedule - [ ] closing an issue - [ ] if the resolution is other than "fixed", the fix for should be unset to make the release notes more accurate - [ ] if set to fixed, the fix for version MUST be set - [ ] documentation issues - [ ] documentation is versioned, while the project site is not - [ ] the project site should have it's own jira project - [ ] documentation issues should be scheduled like any other component of the system - [ ] working on issues - [ ] always assign to self before starting to avoid conflict and give a heads up - [ ] setting the issue in progress is preferable, esp. for a long running task, once the work is actually under way. - [ ] attempt to keep issues small and completable with a commit rather than leaving open (particularly with a dangling assignment that you are no longer working on)