Distributions should be able to set usage enums for answers and blueprints

[j.c.sackett]

Look at https://launchpad.net/debian/+edit

The only options related to bugs, answers, translations &c are checkboxes.

These fields are using the official_ booleans, rather than usage_enums to determine what to display, though the code is setting the usage enums properly.

The interface should be updated to show the normal range of options: Unknown, Uses Launchpad, External, Not Applicable.

[Curtis Hovey (sinzui)]

Checkboxes make sense for two of these issues because distros are not projects.
    * bug tracking is UNKNOWN or LAUNCHPAD
    * translations is only available to Ubuntu (LAUNCHPAD), all other are UNKNOWN
    * blueprints is full range
    * answers is full range

[Robert Collins (lifeless)]

On Sat, Nov 20, 2010 at 6:19 AM, Curtis Hovey
<email address hidden> wrote:
> Checkboxes make sense for two of these issues because distros are not projects.
>    * bug tracking is UNKNOWN or LAUNCHPAD

Why? I mean, RedHat use bugzilla...

-Rob

[Curtis Hovey (sinzui)]

On Fri, 2010-11-19 at 22:35 +0000, Robert Collins wrote:
> Why? I mean, RedHat use bugzilla...

It does not appear to have been a priority to support this. Probably
because these other communities do not use Lp. There was a request to
set the value from one user last year and I discovered I could not set
it. It is also not a priority to support Fedora and Gentoo packages
names, so all bugs would be against the distro only.

--
__Curtis C. Hovey_________
http://launchpad.net/

[Robert Collins (lifeless)]

On Sat, Nov 20, 2010 at 3:34 PM, Curtis Hovey
<email address hidden> wrote:
> On Fri, 2010-11-19 at 22:35 +0000, Robert Collins wrote:
>> Why? I mean, RedHat use bugzilla...
>
> It does not appear to have been a priority to support this. Probably
> because these other communities do not use Lp. There was a request to
> set the value from one user last year and I discovered I could not set
> it. It is also not a priority to support Fedora and Gentoo packages
> names, so all bugs would be against the distro only.

Ok, so its not *intrinsically* a binary value, we just don't [yet]
have it working the same way products do. Are there bugs for closing
that gap (should we decide to do so in the future as a priority) ?

[Curtis Hovey (sinzui)]

On Sat, 2010-11-20 at 17:37 +0000, Robert Collins wrote:
> Ok, so its not *intrinsically* a binary value, we just don't [yet]
> have it working the same way products do. Are there bugs for closing
> that gap (should we decide to do so in the future as a priority) ?

I don't think there is a bug. No community using Lp is using distros
that do not use Lp to track bugs. Users are not reporting that Lp is
missing bug tracking information, but they do report that Lp should
remove the many useless distros registered.

LP external bug trackers are antonymous from their project; distro bug
trackers are registered and used for bug watches. There is no
relationship between a distro and an external bug tracker.

I have reported related bugs, namely, stop letting user report bugs
against distros that do not use Lp to track bugs, and stop sending bug
emails to those owners. We have fixed the former and I plan to fix the
latter in a few weeks.

[Robert Collins (lifeless)]

On Sun, Nov 21, 2010 at 6:06 PM, Curtis Hovey
<email address hidden> wrote:

> I don't think there is a bug. No community using Lp is using distros
> that do not use Lp to track bugs. Users are not reporting that Lp is
> missing bug tracking information, but they do report that Lp should
> remove the many useless distros registered.

Ubuntu ships things (like plymouth) that are developed in other
distros (Redhat, for the plymouth example). I assume, perhaps
incorrectly, that being able to query, show, search all plymouth bugs
would be useful to Ubuntu developers. The bug tracker federation
support is growing, and this sort of link will be needed eventually to
meet that use case - no?

[Curtis Hovey (sinzui)]

On Sun, 2010-11-21 at 05:22 +0000, Robert Collins wrote:
> Ubuntu ships things (like plymouth) that are developed in other
> distros (Redhat, for the plymouth example). I assume, perhaps
> incorrectly, that being able to query, show, search all plymouth bugs
> would be useful to Ubuntu developers. The bug tracker federation
> support is growing, and this sort of link will be needed eventually to
> meet that use case - no?

We do want to support this. This has some overlap with the "launchpad is
its own upstream" issue, and relates to my upstream-downstream links
branch. mpt and barry both spoke to me about the need for unified bug
listing. plymouth in this case wants to do one search to see its bugs,
and the bugs that are in Ubuntu or all distros. We value unified bug
reports, so we decide not to track bugs in the project, we track them
only in Ubuntu. We know this is wrong, and that is cannot be sustained
as Ubuntu community projects are adopted by other communities.

This example also steps into the source package name problem. Fedora and
Gentoo user often report Lp does not support or know about their
packages. This is true. Gentoo package names are incompatible with
Debian. When users report that a bug affects a package in a non-Debian
distro, they are chooses a package they think is the same. Plymouth is
probably safe to choose. Ack is not. ack-grep != ack != text/ack. Ack is
a kanji checker in Debian, it is a grep replacement in Fedora, and it
does not exist in Gentoo.

--
__Curtis C. Hovey_________
http://launchpad.net/

[Robert Collins (lifeless)]

Agreed - lots of discrete bits of work; I was interested in the
relevant bugs so I could have a look and get a feel for the scope of
delta needed.

[j.c.sackett (jcsackett)]

> Ok, so its not *intrinsically* a binary value, we just don't [yet]
> have it working the same way products do.

On the backend, distributions are using the same enums as products; however, that's not yet exposed to the user. This bug could count as one of the ones filed in the name of exposing that, but it's sounding like there's a sound case for not doing that at this point, aside from blueprints and answers.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r12002 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12002>.