maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject how we handle JIRA versions
Date Wed, 01 Aug 2007 16:48:07 GMT
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)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message