LP 1.1.9 considered harmful (was Re: That need to close bugs?)

Scott Kitterman ubuntu at kitterman.com
Sat Sep 22 16:23:07 UTC 2007


On Saturday 22 September 2007 05:38, Matthew Garrett wrote:
> On Thu, Sep 20, 2007 at 12:58:25PM +0100, Colin Watson wrote:
> > I agree entirely. What drives *me* batty in turn is when people take a
> > confirmed, complete report, ask why it hasn't been fixed yet, and close
> > it as invalid because obviously something that's been around for a
> > couple of releases can't be relevant any more. Or when people reject
> > perfectly valid and complete wishlist bugs (note that it usually takes a
> > lot less for a wishlist bug to be complete) because they should be
> > specifications (they shouldn't, in most cases) or just because they're
> > wishlist. As a developer, I wish I didn't have to spend time checking my
> > bug mail just to make sure that well-intentioned but mistaken triagers
> > aren't taking items off my to-do list that I want to stay there.
>
> Something appears to have flagged all inactive bugs as invalid. Apart
> from generating a ridiculous quantity of email for no obviously good
> reason, a pile of perfectly valid wishlist bugs or issues that require
> further work in the rest of the distribution first have suddenly closed.
> Who on earth thought that this was a good idea?
>
This is apparently by design (at least in part).

The theory (and I don't agree with it) appears to have been that if 
information was asked for from a reporter and it was not gotten for some 
period of time, then an incomplete bug could be marked invalid.

Even if the theory was valid, the current implementation appears to be marking 
all bugs that have been in an incomplete state for 60 days as invalid 
independent of if there has been activity on the bug.  See:

https://bugs.launchpad.net/bugs/141652

for details.

I took about an hour to go through the stack of bugmail I got about this and I 
did not find a single bug that should have been closed (in my opinion) that 
could not have been closed by marking it Fix Released with the bug it's a 
dupe of was marked.  

60 days is to short.  Even if we set a time, there are classes of bugs (such 
as crashes) that even if incomplete are not invalid (a crash bug is always a 
bug).  I don't think bugs should get marked invalid except manually.

In my opinion, there have been a number of feature additions to LP recently 
that were not well thought through.  A few additional examples:

1.  Allowing PPA uploads to auto close bugs. (I know this one is fixed now, 
but it boggles my mind to think how it could have been overlooked)

2  Including a backports release as the current Ubuntu release on the new 
package page (I'm not a fan of the new page, but that aside, the concept is 
not well thought through).

3.  Including changelog fragments on the new package page (easy to find 
incomplete information can be actively dangerous).

I know that the LP developers are working very hard to provide a useful tool.  
This is not meant to be an attack on their efforts or their competence.  The 
real problem (as it appears to me as an outsider) is a lack of process focus 
on good up front design and an excessive faith in "well catch it in the beta" 
to surface flaws.

I promised sabdfl on IRC that I wouldn't exaggerate about problems, so I went 
back through the 1.1.9 release announcement to see if there were any changes 
that had affected me (most don't) that I liked.  I came up with:

* When Launchpad is offline, you will now be able to see if it
   is offline for maintenance or offline unexpectedly.

Finally, I used to be able to add a link to an upstream bug.  I appear to have 
lost that ability for anything that's not "registered" in Launchpad.  I'm not 
about to sit through registering every package I touch to do upstream bug 
linking.

Scott K

P.S.  This is on an Ubuntu list and not an LP list because I think that this 
upgrade is bad for Ubuntu and am concerned about our future productivity if 
the trend continues.  This is an Ubuntu issue.




More information about the Ubuntu-devel-discuss mailing list