My 2c is I don't see any practical value in resolved/closed. They are functionally the same thing, only closed is a PITA because to change it, you have to reopen it. I know many orgs have workflows where the two states mean very different things, but for Struts, I think it would be overkill.
Still, if you want to do something like Paul, that's fine, but I probably won't for my tickets. Don On 8/8/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > I have been doing the same: resolving when finishing the issue and then > closing once the release is finished. > > On 8/7/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > > On 8/7/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote: > > > 2007/8/7, James Mitchell <[EMAIL PROTECTED]>: > > > > > > > > That makes sense to me. I don't remember what the decision was on > > > > that. I think this has more to do with making the release managers > > > > life easier than policy per se. > > > > > > > > I can reopen and resolve if needed. > > > > > > > > > It wasn't an "accusation" for your particular issue. I've seen people > > > closing issues directly (probably at Commons) so maybe this is the > > correct > > > behaviour for Struts. > > > I think that a document should be prepared to inform all developers on > > the > > > correct steps to follow (whatever it is). > > > > The only comment I have is that closing issues before a release is a > > PITA if you use Jira for release notes - and want to make any changes > > (correct version number, change title etc) because if they're closed > > you first have to re-open before you can then edit. > > > > Niall > > > > > > > Ciao > > > Antonio > > > > > > > --------------------------------------------------------------------- > > 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]
