Hi, ----- Original Message ---- From: Steven Parkes <[EMAIL PROTECTED]>
And an observation: shouldn't everything currently in Resolved have a FVs that includes 2.1? I can see optionally adding 2.0.1, too, but since OG: I never specify FV. I bet you will see most issues in Resolved state have no FV. it's already committed to trunk, it's obviously planned to be fixed in 2.1, right? OG: right. We don't know when 2.1 will happen, we don't know wha exactly will be in it, but we do know there will be 2.1. What about adding a Committed field? Looking at the docs, it should be possible. I'm actually more interested in that field then I am in FVs, if not simply because it's a lot less ambiguous and subjective. I don't need to know the release process to interpret it. OG: what would that be used for? Personally, I'm for not going crazy with additions of a bunch of new fields - the more I have to think while working with JIRA, the more I'm going to avoid it. :) I think it could facilitate some things, should we ever want to. I wonder how the RM handles making patch releases. If it were me, tasked OG: Ronald McDonald? I think the only person who actually rolled a release around here is Doug. The rest of us are just theorizing.... but somebody's got to do that. with making a 2.0.1 release (should that be decided) and it was decided to have a lot of the patches in, my to-do list would be all those issues that have FV with 2.0.1 and did not have Committed with 2.0.1. Then I'd update the Jira issues as I did the merges. If it's really a simple release, it might be overkill but as soon as it gets a little complicated, it seems like the tracking would be really handy. Otis --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
