Filing package bug against project requires far too many page loads
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
A bug I reported against Ubuntu's Ubiquity package turned out to be a bug in GTK, so I clicked "Also affects: Project..." to file it against GTK. But the resulting page contains only a commit button, no other controls:
------------
= Confirm project =
Project
_ubiquity_ (_Choose another project_)
_Colin Watson_, the ubiquity registrant, will be notified about this bug.
( Add to Bug Report )
------------
If I click "Choose another project", I get taken to a third page, containing a button and only one other control:
------------
= Record as affecting another project =
Project:
[______
( Continue )
------------
On entering "gtk" and choosing "Continue" (as if there's any other choice!), I get taken to a FOURTH page:
------------
= Confirm project =
Project
_gtk_ (_Choose another project_)
gtk uses GNOME Bug Tracker to track its bugs. If you know this bug has been reported there, you can link to it; Launchpad will keep track of its status for you.
URL: [______
(Optional) The URL of this bug in the remote bug tracker.
There is no bug contact for gtk. This means that there is nobody upstream we can notify about this issue.
( Add to Bug Report )
------------
This is aggravatingly inefficient. Ideally, the second, third, and fourth pages should not exist -- I should be able to file the bug against GTK from the bug report page itself. But even without XmlHttp, there is no reason for the second and third pages to be separate pages; there could be radio buttons for choosing between the associated upstream project and another project, with a field for entering that other project.
Changed in malone: | |
status: | New → Triaged |
importance: | Undecided → Low |
tags: | added: ui |
tags: | added: better-forwarding |