Hi > Hi, > > Carsten Ziegeler schrieb: > > Bertrand Delacretaz wrote: > >> On Fri, Sep 4, 2009 at 2:48 PM, Jukka > Zitting<[email protected]> wrote: > >>> On Fri, Sep 4, 2009 at 2:44 PM, Bertrand > >>> Delacretaz<[email protected]> wrote: > >>>> On Fri, Sep 4, 2009 at 2:31 PM, Felix > Meschberger<[email protected]> wrote: > >>>>> ...At the same time I think it would be a good idea to > >>>>> prevent bugs from being reopened as has been set on > Jackrabbit and other > >>>>> projects... > >>>> What's the idea behind this? Force people to reopen new > issues if a > >>>> problem is not really solved? > >>> In Jackrabbit we mark issues as Resolved when the fix is > in trunk, and > >>> Closed when the fix has been released. > >>> > >>> Once the fix has been released, it can no longer be > changed and thus > >>> it's better to prevent people from reopening the issue. A > new issue > >>> with the correct Affects Version setting should be created in such > >>> cases. > >> Ok, I see the idea and agree. Though...if someone > mistakenly changes > >> an issue to "Closed", is it dead? Or can an administrator change it > >> back? > >> > > Hmm, usually I close an issue if I think it's completly > fixed :) But I > > usually do this before the release. Maybe I'm using a wrong > workflow... > > > > But anyway, I think it should always be possible to reopen > a bug, even > > if the fix has been released. > > > > But on the other hand, I guess, we all are working slightly > different > > with (Jira) issues which makes it even harder :) > > I think, issues resolved/closed and included in a release must not be > opened anymore. Otherwise we come into states where issues spawn more > than one release and it is not clear anymore, what part of the issue > work is in which release. > > Rather I think for such situations we should: > > * create a new issue > * link the two issues > * optionally change the resolution of the closed fix to > something "not completely fixed, see linked issue) > > > > > I personally don't think that we need new states for > documentation or > > testing. Usually people are either doing this anyway, or > are never doing > > it - so a new state doesn't help. > > It does not force us to do tests or documentation, but it may > remind us > to not forget about it (as was the case here). > > It may not completely help, but I suppose it won't harm either. On the > other hand it may help with documentation, in that we can consider > documentation state issues specially.
IMHO it *will* help. At the moment I just let mails from the list in the state of unread to not forget to document something (in many cases it's an JIRA issue which is closed...). At the moment I've got 191 such unread marked mails which isn't handy any more (and a lot to do as well ;-)). If it does not harm I definitifely vote for these new states. best regards mike
