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]
