bugs.launchpad.net/NNNN should redirect to appropriate bug page

What's wrong with http://launchpad.net/bugs/1234?

It's okay, but it doesn't quite fit with everyone elses bug trackers

If bugs.launchpad.net worked, and it should as long as it continues to be used for the bugmail domain, then I agree that bugs.launchpad.net/NNNN should work.

Getting b.l.n to work may require a lot of thought. kiko, SteveA, is it realistic to think that b.l.n will work anytime soon?

We already have three URLs for each bug; a fourth would perhaps be overdoing it. Since bugs.launchpad.net doesn't actually exist, I suggest that bugmail shouldn't pretend to come from there.

On Thu, Jan 12, 2006 at 11:40:01PM -0000, Matthew Paul Thomas wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/2132
>
> Comment:
> We already have three URLs for each bug; a fourth would perhaps be
> overdoing it. Since bugs.launchpad.net doesn't actually exist, I suggest
> that bugmail shouldn't pretend to come from there.

I think bugs.launchpad.net serves as a good name-space separator for
email, so I think it should stay. And I don't see any harm in having
https://bugs.launchpad.net/42 to be equivalent to
https://launchpad.net/bugs/42.

The harm is that every extra URL a thing has (1) is extra code to test and maintain, and (2) makes it less likely that a link to that thing will appear as visited in your browser when it should.

I would classify this as "priority: high" as wishlist bugs go.

I have a Firefox keyword "bug" which redirects to http://bugs.debian.org/%s and what's especially fancy is that this works for both packages and bugs. That is, bugs.debian.org/package redirects to http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package;dist=unstable at the moment, and bugs.debian.org/12345 redirects to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=12345

This also reveals a useful indirection; previously, the "package" variant used to go to a URL which looked quite different. Plumbing issue, surely, but nevertheless a nice feature for the site maintainer, too.

Now, I would really really really like to be able to access Ubuntu bugs just as easily as Debian bugs via a browser keyword.

Currently this is hard (but not impossible, if you are Javascript savvy; the bookmarklet could look at the argument and go to a different URL if it sees a numeric string, i.e. a bug number, and treat everything else as a package.)

From a usability point of view, it is hard to overestimate the value of a "canonical" namespace; if it's intuitive, it's easy to remember and use without a bookmark, and you don't get any surprises.

Putting a redirector in place also frees you from incidental features of Launchpad, in case (gasp) you would ever want to replace or overhaul it so the "back-end" URLs look different (cf. Debian package example above).

The fact that you might end up being redirected and looking at a different URL in the Location: bar than what you typed in should hardly come as a big surprise to anyone in this day and age. People are used to it. Most big sites' start pages redirect to horrendously complex CMS back-end URLs and the really big players generate nasty session-specific URLs, so that you get a 404 and/or an insult if you bookmark or copy-paste the URL. (Oops. Soapbox off. Off! Off I say!)

Era, I have a 'malone' Firefox keyword which works nicely. It links to
https://launchpad.net/bugs/%s

Try it you might like it.

Sheesh. Well, here is a bookmarklet which does it. Only briefly tested, but copy + pasted from similar bookmarklets I have for other services which generally have worked amicably.

The fact that https://launchpad.net/malone/bugs/29760 has stopped working is somehow a symptom of the same problem, IMHO.

(See bug #94392 for a corollary.)

In case it's not obvious, the bookmarklet I posted previously handles both bug numbers and package names like I outlined in comment #7 but it will of course stop working the next time the Launchpad URL infrastructure is overhauled again.

Confirming and setting low importance as per duplicate of this one (bug 92219)

On further investigation, we can't do this, because:
* top-level URLs now belong to projects (e.g. launchpad.net/ubuntu, launchpad.net/firefox)
* projects can have IDs consisting entirely of numerals (e.g. bugs.launchpad.net/1234 shows the bugs filed against the "1234" project)
* even if we tried to disambiguate them by introducing a rule that project IDs must have at least one non-numeric character, we'd still have the problem that bugs can also have non-numeric nicknames, and it would be unreasonable for those nicknames to work in some places and not others.

I just went to file this bug again. Can we pls. fix it.

Nicknames do not matter here, they're rarely pasted unqualified on IRC channels.

It's a redirect, not a canonical URL.; If there's an all numerals project name (daft since we wouldn't be able to package it anyway) then that can be an exception and come first.

(BTW, recently it appears that somebody has broken lp.net/bugs/NNNN, making it all the more important to fix).

Re-open.

On Sun, Jun 01, 2008 at 05:29:00PM -0000, Paul Sladen wrote:
> (BTW, recently it appears that somebody has broken lp.net/bugs/NNNN, making it all the more important to fix).

Visiting https://launchpad.net/bugs/197788 works for me.

I wish this would be fixed too.

http://launchpad.net/bugs/2132 is not discoverable, and it's hard to remember that you must have "bugs" after the hostname (not nothing, not "bug", not "+bug"), and that you must _not_ say bugs.launchpad.net (which seems perverse.)

http://bugs.launchpad.net/2132 is fairly easily discoverable by analogy to other systems, and the user's already on that hostname.

I guess the oops reports would tell how many/how often people try this...

There are currently no namespace conflicts, and the /bugs is redundant on the bugs.launchpad.net domain. The only trickyness might be in our virtual hosting code.

The example I was using to test was:

  https://launchpad.net/bugs/1234

which turns out to be a "private bug"; however the "permissions denied" occurs before the redirect...

Stuart; can the redirect be done at the apache level from:

   bugs.launchpad.net/NNNN -> bugs.launchpad.net/+bugs/NNNN

This was how it was done in the bugzilla days. Then zope will never know; and if somebody registers an all numeric project name (more fool them, and personally I think it should be banned), then they'll just get a bug report in that case.

I mainly navigate Launchpad by URL hacking, as Martin Pool said, bugs are the only part of launchpad I keep forgetting which permutation works. Having bugs.launchpad.net/NNNN mirror, say, bugs.debian.org, would be very very nice.

@Paul Sladen:
For further info about papercuts criteria , pls read > https://wiki.ubuntu.com/PaperCut

mac_v: please elaborate. Are you saying Launchpad bugs are not eligible for the paper cuts project? Or that average users don't try to navigate to bugs by number?

@era:
A paper cut is a minor usability annoyance that an average user would encounter on his/her first day of using a new installation of Ubuntu 9.10. So launchpad bugs doesnt fall in papercuts criteria.

We are now planning on consolidating the LP domains to create a more integrated UI with less feeling of siloization.

As a workaround, use eg http://pad.lv/2132