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]
