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]
>
>
