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?
N
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
"3.3.1, 3.4.0.M1".
*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.
/max
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com