Excellent stuff Brett. Let me know if I can help.
Most of this is equally important for plugins and other maven sub
projects. We should try to make an additional, more general, description
of "versions" that is not tied to MNG.
I have a couple of questions, see inline...
Brett Porter wrote:
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
Hmm, has anyone looked at issues that are in Backlog? If not, what is
the difference between Backlog and Unassigned?
- [ ] actions
- [ ] rename 2.1.x to 2.1
- [ ] create 2.1.x after 2.1
Don't we need 2.1.x *before* 2.1 is released so that we can move "known
issues" to it before the release?
- [ ] 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.
+1
- [ ] 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
How do we educate our users (and ourselves for that matter) on the
difference between documentation and site? Perhaps we can make the pages
look slightly different: a special title prefix/suffix, color scheme,
menu struture.
- [ ] 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)
- [ ] If an issue is too large - clone it to create
smaller and more manageable issues
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
