Bugs should be sent to ubuntu-motu for a trial period

Subscribing motu (sorry, I know I hate this being done too), as I suspect you all have fairly strong feelings on this

-25. I can't see the point of adding it to the MOTU list. The idea of the MOTU list is, as far as I know, for discussion between the Masters of the Universe, and a way for users to get in touch with them. It's not a bugtracker, it should not pretend to be one. I see the discussion about the number of correctly filed, untriaged bugs has already occured, so I won't repeat that here, but in essence, why, when we're already drowning in bugs, take bugs that people apparently will not file in the Ubuntu bugtracker?

The other thing I note is that only certain people are interested in certain sections of MOTU packages. People have different interests, and different specialities - on any given mail, the chance that a developer uses the particular package, let alone knows a lot about the package, and cares about it more highly than other packages with other untriaged bugs, is very slim. Therefore, the majority of the time, for all but one or two developers, these mails will be regarded as spam.

My third problem with all of this is that by prioritizing the reportbug-originated bugs, and getting them given attention, and/or fixed faster, as a human actually sees them in a shorter amount of time, is that it encourages people to continue in the bad behavior (of abusing a mailing list for bugs), which is likely to lead to them continuing to use reportbug for reporting ubuntu bugs, and to encourage others to do so, to get things fixed faster. Rewarding incorrect behavior is *not* a good idea. The better idea is to make the good path to follow as easy as possible, so that the people choose the good path.

A rename sounds like a very good idea - debian-bug or debian-report-bug would be good candidates. Perhaps even include warnings when using it about more effective bug reporting tools (apport, help-->get help online, the email interface to launchpad).

Of course, fixing reportbug so that it behaves correctly in ubuntu, and makes launchpad-parsable bugs would also be nice.

Using the motu list doesn't sound sane to me. Maybe the universe-bugs list instead?

OTOH Sarah already pointed out the right solution: Make it work with LP. -> Also affects LP, maybe we can get good ideas how to really fix this from LP devs.

Launchpad can accept bugs by email.

Also I actually use reportbug-ng as a way of finding debian bugs to link Ubuntu bugs to, and to generate some info when I forward bugs upstream (heavily edited though). Breaking this for me would be annoying.

Actually, sending bug reports to universe-bugs may not be the best idea either. What if someone uses reportbug and files a report in main? Why can't reportbug be fixed to email to LP? Our syncrequest script does it, so it seems that adding GPG support in it should be trivial at best.

But you need the user to have a GPG key and to have it in their LP account.

Another possible solution would be to use python-launchpad-bugs to open a bug report in the web interface. But that sounds like too intrusive changes, and I'm not sure it's possible as of now

I think my original explanation tripped up a bit on terminology, because it's difficult to talk about bugs in a bug reporting tool without being confusing. In this message, I'll talk about bug^1s (ordinary bugs) and bug^2s (bugs in the bug reporting procedure).

The central question is the quantity and quality of bug^1s reported with reportbug. If we got a steady stream of repeatable, reliable bug^1 reports from people that responded to e-mail, it would be worth putting in the effort to make reportbug a viable bug^1 reporting channel. On the other hand, getting one bug^1 a year of the form "I downloaded Debian Ubuntu and now my Internet is acting kinda funny, kthxbye" isn't worth the hassle.

This report is about a bug^2 in the proper destination for bug^1 reports. I'm suggesting that we send bug^1 reports to the maintainers (ubuntu-motu) for a trial period, so that the maintainers can gather information about which of the above scenarios is closer to the truth, then provide an appropriate fix to the bug^2 based on the evidence. We could even have an explicit period - say, 10 bug^1s or 10 months, whichever comes first.

I completely agree that sending bug^1s to the ubuntu-motu list isn't an appropriate way of dealing with bug^1s, but it seems to me the best way of gathering enough data to make a proper determination about how to fix the bug^2.

Launchpad is designed to check that a user has an e-mail address that they respond to before allowing them to send bug^1s, whereas reportbug is designed to allow reports from anyone that can send an e-mail. This is a legitimate design difference in the amount the amount of signal you're prepared to lose in the fight against noise, and is not a bug^2 in either program. Although there are certainly things LP can do to make bug reporting easier for one-timers, and to some extent there are things that reportbug can do to dissuade drive-by bug reports, it's not worth the pain of finding a compromise until we know the quantity and quality of bug^1s we'd be getting.

In terms of name changes, I would prefer that either "report" or "bug" be removed from the package name. My assumption is that most incorrect uses of the package come from people not really paying attention, so it should be impossible for users to hunt through the repository, see "report" and "bug", then ignore the words they don't want to see. Of course, I'd prefer this assumption be backed up with evidence before any decision was made :)

What needs to happen is reportbug and reportbug-ng need to be taught to report to Launchpad. For this to be done reliably, LP needs to expose and API and it needs to be implemented in python-launchpad to get possible duplicates. This does not currently exist. Until then, it really doesn't matter what ML you send bugs to. Mailing lists are poor bug trackers no matter who reads them.

I really don't think we want to get rid of reportbug altogether. It is very useful when dealing with Debian BTS. I think rather it would be a good idea to make it useful for Ubuntu people. Can we make reportbug not send *any* emails for Ubuntu? Since we use Launchpad for bug reports perhaps it would be best if reportbug just spit out text that would be appropriate to add to Launchpad. It could have a header that said something like "To report this bug please visit http://launchpad.net/ubuntu/+filebug. You can use the following text in your bug report:" this would allow people to properly file bugs, doesn't go to mailing lists, and allows developers to use it for working with Debian.

Sending bugs via email only makes sense when the bug reception engine expects email. As a result, the appropriate means to map the behaviour of sending to the BTS is to send to the LP mail interface. While this has the side effect of possibly generating duplicate or inadequate bugs, this is also true for this functionality within the BTS. Further, it makes sense to leverage ptyhon-launchpad to generate canidate duplicates, etc.

Extending these tools to provide a different service, specifically to integrate with launchpad in a different way is really creating a new tool. Sending people to a webpage (e.g. https://launchpad.net/ubuntu/+filebug) doesn't map well to many of the use cases where a user might be using reportbug or reportbug-ng (e.g. not having a web browser installed).

Handling these requests is a different matter, but I submit that if LP is going to accept bugs by use of the email interface, it is no different to have LP accept bugs by use of various Debian BTS-oriented tools that may benefit from a patch. How these bugs are handled is a different matter: if triage of these is expected to be a considerable additional load (remembering that LP requires signed mail and a valid account), how is this different from any other use of the LP mail interface?

I'm of the opinion that, whatever the end result of this discussion, users should be discouraged from reporting bugs via reportbug. Although it collects more information than alternatives, the interface is unfriendly to non-experts, and it doesn't provide any way of checking for Ubuntu bugs.

If nobody disagrees with the above assessment, I'll open up a separate bug about ways to make the reportbug and reportbug-ng packages less attractive to non-developers.

On the question of what to actually do with bug reports once they've been written, I went into #ubuntuforums and asked for opinions of ubuntu-users subscribers. The complete conversation is attached, but here are some of the highlights:

* A couple of bugs get reported through reportbug every month
* They tend to be actually useful bug reports - people who know to use reportbug on Ubuntu generally have a clue
* At least the one kind soul I talked to tends to forward bugs to Launchpad
* When I asked, there wasn't an avalanche of complaints about reportbug. This suggesting that reportbug doesn't put a terrific strain on the ML it goes to

My thanks go to crimsun in #ubuntuforums for this information.

Closing the Launchpad task as making the reportbug work with LP is bug 31508.
There is also bug 50653, which is about allowing LP to receive anonymous bug reports.
Also check out https://help.launchpad.net/MaloneXMLRPC for a way to programmatically file bugs into LP.

Would it not be possible to expand on a solution,

eg: keep the motu-list as it is, and have an motu-bug list, that could be subscribed to if desired, and/or assign people the responsability of gatekeeping that list, eg: removing duplicates, cleaning up the quality, and then posting a summary Bug report to the motu list so that only quality gets onto the main list removing the user based spam eg: "I want package verison X+1".

Assigning a sub section of the MOTU group to house keep this and feed to the core list may be a way to go ?

I suspect as mentioned above that the noise ratio would increase, and lot of it would be lacking in a quality bug report (judging by a lot of the quality of generic bug reports on launchpad)

I think it's better to just fix it once and do it right, but I've no objection to this is as it's completely opt-in.

Hi all,

As I see it if we patch reportbug to simply to "apport-cli -f -p <package>"
when reporting to Ubuntu then we get bug reports going to the correct
place, with little effort.

I see there was concern expressed that this may not fit in with some
developers way of working. For instance it would not work well in
text mode, which some people may like to use.

Would it be acceptable to do this by default, but have a way to file
a signed report to lp as well? There is already a --sign option, so this
could be used to indicate that the reporter wants to use the email
method. There would however still be more work to do to present
the lp bug information through the reportbug interface.

Thanks,

James

I think this would be a definite step forward. It'd be good to do this in
reportbug and reportbug-ng. Also, reportbug is needing a merge, so I'd
combine this change with a merge if you do it.

I'm currently looking into removing most of Ubuntu's delta from reportbug and let it exit with an error in case bts=ubuntu is used/detected.
This would include a pointer to "ubuntu-bug" and all should be fine.
IMHO it makes not much sense to call ubuntu-bug/apport-cli from reportbug, if the user should use it directly for bug reports in Ubuntu anyway.

Please speak up, in case you see any problem with this.

This does not mean, that we cannot add support for Launchpad later, but currently this seems to be the least intrusive change and would leave reportbug around for those who report bugs to Debian with it.

Daniel Hahler wrote:
> I'm currently looking into removing most of Ubuntu's delta from reportbug [...]

> Please speak up, in case you see any problem with this.

The problem with that is that some users install reportbug and use it to send
bugs, thinking that it will send bugs to Ubuntu, while they are sent to Debian.

I have a problem with that, but there's an easy solution: if
~/.reportbug-i_really_want_to_send_bugs_to_debian exist.

Thanks,
Emilio

It's easy enough to point the default BTS back to Debian in the conf file.

Emilio, I've just used the following logic: if "bts" is not configured (which it is now by default), or is "ubuntu", the error with the link to ubuntu-bug will appear.

That keeps existing "bts=debian" installations just working and in case of new installs, "bts" is undefined now: you have to configure it to "debian" to make it work. IMHO that's as good as some hidden ACK-style file.
The only issue might be with upgrades, where bts is "debian" already (e.g. in /etc/reportbugrc (and the admin does not use the new conffile) or ~/.reportbugrc), but the user still thinks it would send the bug to Ubuntu.

The package/mechanism can still be improved, of course. But for now I think it's the best solution.

Daniel Hahler wrote:
> Emilio, I've just used the following logic: if "bts" is not configured
> (which it is now by default), or is "ubuntu", the error with the link to
> ubuntu-bug will appear.

Sounds reasonable. Thank you

I'm closing this bug as Invalid.

I'd say to file any new issues/ideas/requests as separate bug reports.

Thank you for all the feedback.