So you'd rather move issues one by one into the M1 bucket, than to move
them out of the bucket and into a M2 bucket? Isn't that how we've
triaged the 3.3.0.* issues?
(That's how I've been working -- put stuff in Beta1 and watch it slip
out (as it became less important) to Beta2, 3, CR1, GA, 3.3.1, etc.).
Maybe it's time for a "how the team uses JIRA fixversion field" document
in the wiki?
On 05/30/2012 05:16 AM, Max Rydahl Andersen wrote:
> I have bulk moved all 268 issues slated for the mythical 3.4.x release to an actual
milestone so we can better plan things and start the usual triage/prioritization.
so that explains it - gawd thats annoying - I wanted to keep the 3.4.0.M1 *minimal* and
selective instead of long winded always bumping issues ;(
> This will also prevent Max's jiralint job from complaining should any of these
issues be closed w/o updating the fix version.
What prevents this from complaining is that you don't resolve issues without checking
what version you've set on fix version.
> If you would like subsequent milestones to be created (M2, M3) or Beta/CR targets to
be created, I can do so too - just ask!
> For now though, it seems a bit premature as we don't have a schedule yet for the
3.4 release stream. :)
> If I moved an issue you had scheduled for fixVersion "3.3.x, 3.4.x" and you
want to move it back to the two targets, feel free. You might instead want to use
*NO* - we need to stop that madness.
Jira fixversion should be useful, not just a garbage can for 268 issues that for sure is
not being fixed in time for that.
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio