Filing a bug: source package doesnt exist, suggestion list doesn't accept input

On 16-Jan-06, at 9:08 AM, Trent Lloyd wrote:

> Public bug reported:
> https://launchpad.net/malone/bugs/28682
>
> Affects: launchpad (upstream)
> Severity: Normal
> Priority: (none set)
> Status: Unconfirmed
>
> Description:
> If you try to file a bug on a package that doesn't exist (e.g. i used
> 'mysql')
>
> it comes up with a drop down of suggestions, my first instinct was to
> select a suggestion from the box, which doesn't work, and that isn't
> very obvious.

Hi Trent,

Can you provide the URL at which you're seeing this problem?

  status needsinfo

Cheers,

--
Brad Bollenbach

OK so this behavior has changed..

So I goto
https://launchpad.net/distros/ubuntu/+filebug

I file a bug again 'mysql'

it used to then bring up a list of packages like mysql to choose from, now it just makes a comment that it doesn't exist

e.g. https://launchpad.net/distros/ubuntu/+bug/33491

Im not sure thats the best idea?

Well, this issue is rather difficult to handle. I'll elaborate on what happens and then perhaps we can see if there's a better solution.

There were two changes implemented that affect this:
- First, the input widget used for entering the sourcepackage name now [only] matches exact strings. So if you enter "my" it will fail and show you options containing that fragment, but if you enter "mysql" it will do an exact match, find the package name, and then move on.

- The next step after that is verifying whether there is a package with that name published in Ubuntu. There is no source or binary package called "mysql" in Ubuntu -- there is mysql-dfsg-5.0 (as apt-cache showsrc mysql-dfsg-5.0 will show you however)

Given that we were unable to find a package with that name in Ubuntu, we add the comment and life goes on. The person triaging Ubuntu bugs can use that information to assign to the correct package, so I think it's not the worst solution, but there may be better ones.

One thing we could do would be changing the input widget to /never/ match, and always force you to confirm the package name. I'm not sure how good that would be unless it was implemented using AJAX, because forcing people to reload that form would be silly.

On Tue, Mar 07, 2006 at 08:26:53PM -0000, Christian Reis wrote:
> One thing we could do would be changing the input widget to /never/
> match, and always force you to confirm the package name. I'm not sure
> how good that would be unless it was implemented using AJAX, because
> forcing people to reload that form would be silly.

That sounds like a bad idea, I think it will annoy a lot of people.
Why not change the vocabulary, so that only published packages will be
included?

On Tue, Mar 07, 2006 at 09:30:04PM -0000, Björn Tillenius wrote:
> That sounds like a bad idea, I think it will annoy a lot of people.

Right; that's why I suggested AJAX. I was thinking of this in
combination with a selector that allowed you to indicate clearly you
didn't know (or didn't want to specify) a package name.

> Why not change the vocabulary, so that only published packages will be
> included?

That's an alternative I hadn't considered. We could do that, and the
user would have to either choose the right one or give up. I wonder why
Brad didn't use this approach when implementing the binarypackagename
bug-filing feature. Do you know?
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125

The dropdown widget is a Zopeism; it's hard to imagine that a user trying to find their way around Malone can make sense of that UI. It's hard to even notice how the screen has changed, at first.

In an ideal world I'd suggest an intermediate screen that says something like:

We were unable to find an exact match for the package you specified. Please choose the nearest match below:

  (*) [ mozilla-firefox ]
  ( ) I don't know

( Submit Bug Report )

This could possibly be done on the main form, if the widget can be modified to draw clear attention to what the user needs to do to fix the problem (i.e. to choose an option from the dropdown, or choose I don't know.)

It seems reasonable to ensure this widget searches/shows only published packages.

Oh, and as for /why/ I didn't restrict it to published packages before:

1. Because many packages in our sampledata didn't have proper publishing records (and, I'm guessing, still don't.)

2. I didn't think it would make a difference in production, because I didn't see how we'd get a bunch of unpublished packages in our production data.

Is this related to bug 52549?