Launchpad bug statuses

[Scott Kitterman]

On Thursday 04 October 2007 03:15, Emmet Hikory wrote:
> On 10/4/07, Scott Kitterman <ubuntu at kitterman.com> wrote:
> > On Thursday 04 October 2007 01:00, Emmet Hikory wrote:
> > >    ... The parallel case of rejecting bugs
> > > for which nothing is happening is already established as a manual
> > > workflow (at least for Ubuntu), and so does not become worse through
> > > automation (regardless of any perceived benefits or detriments to
> > > users, reporters, triagers, contributors, developers, etc.).
> >
> > I pretty strongly disagree with this.
> >
> > Different teams and projects have different standards for how long is
> > long enough.  In Ubuntu Backports we don't (until LP took away the
> > choice) close bugs that have been incomplete as they are usually
> > incomplete due to lack of sufficient testing.  This testing, depending on
> > the package in question, may take quite some time.
>
>     Thank you for the counterexample.  I'm in agreement that automated
> adjustment of bug status can be dangerous, but was unaware of existing
> processes that were broken by the automation of bug invalidation (as
> opposed to the ongoing manual invalidation documented by the
> bugsquad).  In any case, I believe this particular issue was well
> discussed in a separate thread previously, and that further
> adjustments are underway (if I interpret the launchpad-users archive
> from late September correctly).

Which, as I understand it, was that bugs that were incorrectly (according to 
the automatic expiration design) closed were going to be rolled back.  
Fundamentally, we are still stuck with automatic expiring bugs whether we 
want them or not.

> > My perception is that LP developers have a "right" way to use LP in mind
> > and do not appear to be very open to alternate visions.  As an Ubuntu
> > developer, LP is a tool to work on Ubuntu and so the end state of the
> > distro at release and through updates is what matters, not the purity of
> > the bug database.
>
>     Personally, I believe it is in the interest of a strong final
> product for developers to have a concept of the "right" way for things
> to be done, and for new workflows to be added to the list of use cases
> for the system as it matures, rather than being imposed externally.
> With a strong set of use cases, and a shared understanding of terms,
> it should be possible to both provide for a comfortable workflow for
> development and maintain the purity of the bug database.  Having a
> single extended workflow for all Ubuntu teams would likely make it
> even easier for new people to help, and improve the end state of the
> distro at release (assuming a smooth transition to a workflow with
> comprehensive support).

I guess I come at it the other way.

I have a personal workflow that I've developed in that last ~ year of working 
on Ubuntu.  As LP evolves, it is my perception that it is getting more and 
more in the way of that workflow.  Having a standard way to do things is 
good.  Having one and only one way to do things is not good.

From my perspective the "being imposed externally" is LP imposing on Ubuntu.

It isn't all one way mind you.  I have worked with the LP developers providing 
feedback and filing bugs and there is some responsiveness.  As an example, I 
find the edge version of the source package page much more useful that the 
current production version.  OTOH, I like both of them significantly less 
than the old one.

Scott K