In its current released version, 2.0-beta-2, it is busted. But the
latest beta-3-SNAPSHOT should work. I've done some work on it, but there
are still issues with it - see the "jira-report" component at
http://jira.codehaus.org/browse/MCHANGES
Brett Porter wrote:
the changes report does include that, but I'm not sure how complete it is.
On 02/08/2007, at 4:24 PM, [EMAIL PROTECTED] wrote:
Does anyone know if there is a mvn plugin to generate release note
reports for mvn site from a jira version? This would be really useful
IMO. Was thinking about this for a while... Should be easy enough to
impl... But does it already exist?
--jason
-----Original Message-----
From: Jason van Zyl <[EMAIL PROTECTED]>
Date: Wed, 1 Aug 2007 23:22:12
To:"Maven Developers List" <dev@maven.apache.org>
Subject: Re: how we handle JIRA versions
All looks good, my only comments are I think the notions in Scrum
like Sprints for a release are good like the idea of fixing the set
of issues and sticking with it for the Sprint. Sensible patterns and
there's already literature on that. So in any parts you're talking
about planning I think it might be good to defer to Scrum.
To sustain any sort of visibility amongst us I think it would be wise
for us to mandate the use of Mylyn. I don't use Eclipse but I use
Eclipse for Mylyn. For anyone using Eclipse it's a no brainer, but I
don't use Eclipse 100% of the time but I use it for Mylyn. It makes
being diligent about issue management a lot easier. It also helps vet
duplicates, and generally makes planning easier. At least I've found
it to be a great boon after using it for quite a while now.
As far as the workflow, are you actually going to try and encapsulate
that workflow in a JIRA workflow itself? I think that might be a bit
masochistic but any workflow that is not strictly enforced in the
tool is going to be hard to adhere to.
On 1 Aug 07, at 12:48 PM 1 Aug 07, 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
- [ ] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
