Hello all!
Two things about the approval during the alpha and beta period.
There is no need to have a certain priority on the issue to request it to be
approved. The reason for approving issues is to avoid that fixes causes new
problems that we need to handle. If a patch to an issue with priority P3,
P4, or P5 is low-risk and the problem to fix is important enough, then it
can be considered. (There is a connection between the importance of an issue
and the priority but it is secondary in this work).
Please be explicit on what patch you want to get approved! Make sure I am on
the CC-list of the issue and write an explicit comment about that you want
the patch to be approved or mail me directly.
/Linus
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]
>
>
