Sorting out upstream and project bugtrackers
Bjorn Tillenius
bjorn.tillenius at gmail.com
Fri Aug 25 11:37:40 BST 2006
On Wed, Aug 23, 2006 at 01:20:04PM +0300, Matthew Paul Thomas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Aug 16, 2006, at 11:53 PM, Christian Robottom Reis wrote:
> >
> > I had a call with Bjorn today to define how our handling of bugtrackers
> > could be improved, as part of his work in improving forwarding of bugs
> > to upstream. The current system allows you to register a standalone
> > bugtracker, and it also allows you to register a bugtracker associated
> > with a project, and there is no way of changing that association after
> > creation -- which is a wart! There is also now way of specifying that a
> > certain product uses a bugtracker, which means we can't direct the user
> > to a specific bugtracker when he wants to add a new watch -- we end up
> > with that sucky drop-down listing all registered bugtrackers.
> > ...
>
> If I want to link a bug report in Launchpad to a bug report in a
> separate bug tracker, in 99% of cases I will have that external bug
> report open in front of me. So I think the ultimate goal should be to
> let me drag the URL from that browser window and drop it into an
> "External bug report:" field in Launchpad. ANYTHING else I have to do
> - -- "registering" bug trackers, selecting from a list of "registered"
> bug trackers, "associating" bug trackers with projects, etc -- is
> process waffle that should be eliminated with a vengeance.
I agree, you shouldn't have to register a new bug tracker just to link
a bug to it. But as you say, we are a long way from it, and it won't
get done in the near future.
> We're quite a long way from allowing that, unfortunately, but there are
> several intermediate improvements that could be implemented separately:
>
> 1. Fix the bug that currently requires the Sourceforge bug tracker to
> be registered eleven times (!) in Launchpad. (We don't need
> bugzilla.mozilla.org to be registered separately for each of
> Firefox, Thunderbird, Seamonkey, etc, so we shouldn't need
> sourceforge.net/tracker to be registered separately for each
> Sourceforge project.)
>
> 2. Replace the current bug watch UI with a text field that, given a bug
> report URL from an already-registered bug tracker, works out which
> one it is.
This has been discussed, and it's something we're going to do. See
http://www.async.com.br/~kiko/mockups/bug-forwarding-workflow.html for
a few ideas.
> 3. Replace the current association of bug trackers to
> products/projects/distributions with a non-interrupting system
> similar to that for rarely-used bug tags: "99.8% of Fooix bugs are
> recorded in bugs.example.org, not bugzilla.gnome.org. Check that you
> entered the right URL in the right field."
This sounds reasonable. Although personally I think there's some value
in having an 'official' bug tracker, even though no bugs have been
linked to it from Launchpad. We could easily associate a product with a
bug tracker the first time a bug watch is created for a product, in a
similar non-interrupting way you propose.
> 4. Remove or make optional the "Title", "Summary", and "Contact
> Details" fields for registering a bug tracker.
Agreed. I think Name should be optional as well. We can autogenerate it
from the URL if needed.
> 5. (The hard part) Write code that, given a bug report URL from a
> previously-unregistered bug tracker, probes the URL to see what kind
> of bug tracker it is.
This is actually not too hard. It's not too different from looking at
the URL (which we already do today) and come up with a few good
heuristics. But sure, it requires some work to get it to work, and I'm
not sure it wins us much compared to prompting the user for the
information. You only have to do it once per bug tracker, and we can
guess the type from the URL, asking the user if it's correct.
> 6. If I enter a URL for a bug tracker that isn't currently registered,
> send me to a "one moment, please" page for 20 seconds while
> Launchpad probes the URL, registers the bug tracker automatically,
> and gets the remote bug's status, then redirect me back to the bug
> page with the shiny new remote bug status highlighted.
>
> Should this be a spec? :-)
That would be great, thanks! ;) There are some thoughts in the mockups above,
and there's also some discussion in
https://wiki.ubuntu.com/BugForwardingWorkflow, but nothing concrete has
been written down.
Regards,
Bjorn
More information about the launchpad-users
mailing list