I've reported all the information that I have on this topic. I haven't had a chance to do any further investigation.
It's strange that a new issue all of a sudden showed up as UNCONFIRMED, but I guess I'll just chalk that up to Tigris weirdness. Tom On Sat, Sep 27, 2008 at 12:44 PM, Linus Tolke <[EMAIL PROTECTED]> wrote: > I have not changed anything around this since I concluded that it wasn't > working several years ago. I had hoped that you would describe exactly how > to do the configuration to make use of the UNCONFIRMED status. > > /Linus > > 2008/9/26 Tom Morris <[EMAIL PROTECTED]> >> >> The latest bug report that I created just came up in UNCONFIRMED >> status. Has this been implemented now? What's the new workflow? >> >> If it's possible, it'd be nice to have bug reports created by >> developers (as opposed to users) be automatically confirmed to NEW >> status, but I can live with the extra work if it makes it easier to >> track bugs which haven't been triaged/acknowledged. >> >> Tom >> >> On Sun, Sep 21, 2008 at 9:53 AM, Tom Morris <[EMAIL PROTECTED]> wrote: >> > On Sun, Sep 21, 2008 at 5:51 AM, Linus Tolke <[EMAIL PROTECTED]> wrote: >> > >> >> Are you saying that you have gotten the change in issuezilla to work as >> >> you >> >> want in the ArgoEclipse project? >> > >> > If you're asking about getting bugs created in the UNCONFIRMED state, >> > no, I haven't actually implemented this. All the information that I >> > have on it was included in the email quoted below. The help text said >> > that it's only for people creating bugs who don't have the right >> > privileges. I haven't yet gone through to figure out how to remove >> > the privileges from the default Observer role. If I decide to use a >> > different bug reporting system, I probably won't invest the effort in >> > trying to figure out Collabnet's IssueZilla system. >> > >> > Tom >> > >> >> >> >> >> >> 2008/9/20 Tom Morris <[EMAIL PROTECTED]> >> >>> >> >>> On Wed, Sep 10, 2008 at 5:54 PM, Dave Thompson <[EMAIL PROTECTED]> >> >>> wrote: >> >>> >> >>> > I'm wondering about the usefulness of our issue life cycle. >> >>> > >> >>> > Aside from reopened/unconfirmed issues, the usual workflow as >> >>> > defined in >> >>> > the cookbook >> >>> > >> >>> > >> >>> > (http://argouml-stats.tigris.org/documentation/defaulthtml/cookbook/ch09.html) >> >>> > is: >> >>> > >> >>> > New >> >>> > Started >> >>> > Resolved >> >>> > Verified >> >>> > Closed >> >>> >> >>> I've tried a couple of times over the past three years to get some >> >>> improvements on the other end of the issue life cycle. Perhaps it's a >> >>> good time to attempt to get this fixed again: >> >>> >> >>> >> >>> http://argouml.tigris.org/servlets/SearchList?list=dev&searchText=unconfirmed&defaultField=body&Search=Search >> >>> (BTW, 3 year turnaround times is why I've completely given up on >> >>> suggesting any type of process improvements) >> >>> >> >>> Basically the goal was to find some way to make sure that all new bugs >> >>> get triaged in some reasonable amount of time (TBD) so that bug >> >>> reporters perceived the development team as at least somewhat >> >>> responsive. The triaging would make sure that the bug had the right >> >>> priority and was assigned to the correct component. If everything was >> >>> fine, then it would involve a simple ack to the user to acknowledge >> >>> that we had accepted their bug report. >> >>> >> >>> Part of the problem is that we have a large number of components which >> >>> are either unowned or owned by "developers" who have disappeared. If >> >>> the bug reporter chooses one of these components, there's a very real >> >>> chance that literally YEARS will go by before anyone even looks at >> >>> their bug report. >> >>> >> >>> I recently looked at the Tigris issue reporting for ArgoEclipse >> >>> because I want to choose a decent bug tracking system before we >> >>> accumulate too many bug reports. As best I can tell, to get the >> >>> UNCONFIRMED state to work, you'd need to remove the "Can submit >> >>> confirmed bug reports" privilege from the Observer role. >> >>> >> >>> Also, the infrastructure that they have to make sure that bugs don't >> >>> get lost (the "Whine" facility) doesn't really match up with the way >> >>> the ArgoUML issue states work. Whine (optionally) kicks in when a bug >> >>> has been in the NEW state for more than a certain threshold. This >> >>> implies that the triage takes place during the NEW->STARTED transition >> >>> when the bug is accepted, but we typically don't accept a bug until >> >>> work actually starts on it. >> >>> >> >>> Another problem I see with the current system is the use of arbitrary >> >>> bug priorities to trigger desired behaviors such as stop a release or >> >>> force Linus to review a patch. I think it would be much better to not >> >>> overload/abuse the priority in this manner. Also, a regression isn't, >> >>> in my opinion, automatically a showstopper/blocker. >> >>> >> >>> Tom >> >>> >> >>> --------------------------------------------------------------------- >> >>> 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] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
