9495
Comment: syncSource problems
|
10345
Define priorities for all ideas
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
|| '''Launchpad contact''' || [[https://launchpad.net/~jml|Jonathan Lange]] || || '''Ubuntu contact''' || ??? || |
|| '''Launchpad contact''' || [[https://launchpad.net/~flacoste|Francis Lacoste]] || || '''Ubuntu contact''' || [[https://launchpad.net/~bryce|Bryce Harrington]] || |
Line 7: | Line 7: |
1. Monitoring of Debian bugs * Tracked at: '''https://blueprints.edge.launchpad.net/malone/+spec/debian-bug-import-continuous-imports''' * Rationale: Nearly all Debian bugs also affect Ubuntu, and Debian's larger base of developers can find and fix a higher volume of bugs. We should be informed of these bugs so that we can make a decision about whether to act on them. * Status: * A script exists to import bugs from debbugs into Launchpad: '''https://blueprints.launchpad.net/malone/+spec/debian-bug-import-on-demand''' * Launchpad can already import comments from debbugs, and send replies back to debbugs. A separate issue is whether or not we proactively import ALL Debian bugs into Launchpad, or whether we only import a subset of bugs (say, RC bugs), or whether we only import Debian bugs which have been manually correlated to Ubuntu bugs. * '''https://blueprints.launchpad.net/malone/+spec/upstream-bug-searching-and-filing'''. The expensive implementation depends on bugzilla-launchpad-identification. * Depends on BugTrackerImport.context * From also-affects-upstream: * Offer link to search first and say "(opens in new window)" * Group in sections: * "Didn't find your bug?": Offer a button that says "Report bug upstream (requires account in bugzilla.gnome.org) (opens in new window)" * Offer a box to enter the existing bug URL * Post to enter_bug.cgi form containing: * description (include URL to Launchpad bug) - summary * product (which comes from BugTrackerImport.context) * User is redirected to login, he uses his credentials and then bug is filed. * demo URL: http://people.ubuntu.com/~jamesh/file-bug-gnome.html * Less cheap would include a special plugin for GNOME bugzilla to provide a URL to redirect the end-user to a special URL. The "from-launchpad" keyword would be useful as well. * If we import bugs regularly, bug watches can be created at scan time. * Ideas: * Create non-Launchpad infrastructure to monitor bugs - Where to get notification addresses? Scrape launchpad? * MoM's bug notifications could be the basis of a partial solution |
|
Line 35: | Line 11: |
* Status: Some of the steps for this to happen are implemented. Additional work includes: * The "no upstream bug tracker exists" use case, which is described in '''https://blueprints.launchpad.net/malone/+spec/forwarding-to-email-address''' (Done?) * Comment synching to enable inter-bug-tracker replies (Done?) * Map remote bugtracker product/component to source package: '''https://dev.launchpad.net/LEP/BugzillaComponents''' (Nearly done) * Forwarding of selected attachments from LP bug to upstream - '''https://dev.launchpad.net/LEP/ForwardAttachmentsUpstream''' * Automatic user registration in remote tracker * Automatic fill-in of upstream bug report fields (title, description, priority, cc, etc.) |
|
Line 36: | Line 19: |
* Status: Some of the steps for this to happen are implemented. Additional work includes: * The "no upstream bug tracker exists" use case, which is described in '''https://blueprints.launchpad.net/malone/+spec/forwarding-to-email-address''' * Simplified/automatic filing of bugs in an external bug tracker * Comment synching to enable inter-bug-tracker replies |
1. Only Series Tasks * Tracked at: * https://dev.launchpad.net/LEP/OnlySeriesTasks * 20111103 - https://blueprints.launchpad.net/ubuntu/+spec/other-p-bugtaskseries * Bugs 314432, 777861, ... * Rationale: Many times bugs are specific to a particular version of Ubuntu, but this is not tracked by Launchpad. We work around this by tagging bugs with the release codename but this is done inconsistently (apport will include the tag automatically, but non-apport filed bugs don't). There are various bugs, features, and usability issues for which being able to segregate bugs by series would be a possible solution. * Status: ??? (I've heard it's proposed but not yet on the schedule.) 1. Temporarily adding the uploader as a bug contact for the package being uploaded * Tracked: ?? * Rationale: Our development model is such that packages are often uploaded by a developer who has no ongoing relationship with the package. Because they do not receive bug reports for the package, it is easy for them to be unaware of having introduced a regression. * Status: * '''https://bugs.launchpad.net/malone/+bug/3882''' 1. git support. Native git hosting. * Tracked: ?? * Rationale: While bzr is awesome, many projects use git instead. Launchpad's utility to the broader community would thus be improved if it was able to host git-based projects. 1. Wiki support integrated throughout Launchpad. * Tracked: Bug:240067, Bug:254167, Bug:797331, [[https://dev.launchpad.net/VersionFourDotO/OutOfScope/Blueprints|Wiki markup in blueprints]] * Rationale: We need wiki-like markup (including tables), revision tracking, and easy cross-linking to other LP entities so we can display information to users more clearly and orderly, and to keep track of changes made to our pages. E.g. PPA descriptions, project home/about pages, blueprints, whiteboards, etc. 1. QA status/workflow tracking. * Tracked: ?? * Rationale: Testing and quality control are becoming increasingly important to Ubuntu, yet Launchpad provides little in the way of built-in QA tracking supports. * Need ways to better flag bugs/branches/patches/etc. as needing testing, passed testing, failed testing, and so on. Ideally should also support hooking into automated testing in some fashion, with the goal of being able to delineate between code ready to be released from that needing additional work. |
Line 43: | Line 48: |
'''''NOTE: Some of this section may be already implemented. We're porting over notes from early 2009; it's now late 2009.''''' | 1. Package version tracking for bugs (shortcoming of Launchpad relative to debbugs) * Rationale: Some bugs are particular to a specific version of a given package, or are fixes as of a given version. Currently Launchpad doesn't track this so we have to ask for this info every time a bug is filed. If it's filed with apport this generally will attach the info automatically, but many bugs aren't filed with apport. |
Line 45: | Line 51: |
1. Rebuild testing in Launchpad * Tracked at: '''internal RT #34356''' * Rationale: Rebuild testing is currently performed using a dak instance. Failures must be processed manually by a buildd admin and the relevant developers notified. This requires maintaining redundant infrastructure and more manual work than should be necessary. * Status * As of 2009-05-15: Largely done; test currently in progress at https://launchpad.net/ubuntu/+archive/test-rebuild-20090513 (summary at http://people.ubuntuwire.com/~wgrant/rebuild-ftbfs-test/). Remaining omission is that the rebuild archive is not published and therefore is unable to use its own output (internal RT #34356). 1. Web interface for syncing source packages in Soyuz, accessible to those with corresponding upload privileges * Tracked at: '''???''' * Rationale: "Syncing", i.e. copying source packages verbatim from one distribution to another, is a very common operation in Ubuntu, and is often requested by developers either after automatic syncs from Debian stop a couple of months into the release cycle, or when all changes have been incorporated into Debian and the Ubuntu changes may be discarded. At present, this operation is restricted to those with privileged shell access to the production archive. Conceptually, it should only require upload access to the corresponding component. Allowing uploaders to perform this task would save on the order of an hour a day of archive administrator time performing trivial requests. Syncing should also be possible from PPAs * Status: * Debian sources now available in Launchpad database, updated twice daily, making this more feasible * syncSource method available in API * Some problems with changelog presentation in web UI and in mails to -changes lists; '''https://bugs.launchpad.net/soyuz/+bug/55795''' documents part of this * syncSource does not put syncs through the standard upload queues: '''https://bugs.launchpad.net/soyuz/+bug/529936''' * syncSource permissions are not open to package uploaders (must be resolved after the above two problems): '''https://bugs.launchpad.net/soyuz/+bug/529933''' == Low priority == 1. Opening a new distrorelease before releasing the previous one (shortcoming relative to former dak infrastructure) * Tracked at: '''https://bugs.launchpad.net/soyuz/+bug/87012''' * Rationale: When opening a new distrorelease, uploads must be temporarily blocked until the toolchain and other basic infrastructure are in place. Opening the new release early would allow this work to happen in parallel, so that the new release would be immediately open for development. * Status: * PPAs make it possible to do some of the preparatory work for a new distro series * Fully handling this was not targeted for Launchpad 4.0 1. Improved activity logging * Tracked at: '''???''' * Rationale: The current activity log in the Launchpad bug tracking system does not capture milestone changes. This presents a problem for release managers, who have no way to tell whether the milestone on a bug was set by somebody they trust, or whom to contact about it if the person who milestoned the bug omitted to leave a comment. * Note that milestones are not designed to be tightly controlled, we have tight control of release-critical bugs targeted to the specific series, where only drivers can approve the bug as RC. * Status: Apparently needs a [[https://blueprints.launchpad.net/malone/+spec/bug-history|rewrite of the activity log]]. * '''https://bugs.launchpad.net/malone/+bug/65660''' (Joey: Fix Released) * Not targeted in Launchpad 4.0 1. Temporarily adding the uploader as a bug contact for the package being uploaded * Rationale: Our development model is such that packages are often uploaded by a developer who has no ongoing relationship with the package. Because they do not receive bug reports for the package, it is easy for them to be unaware of having introduced a regression. * Status: * '''https://bugs.launchpad.net/malone/+bug/3882''' |
1. Bug Q&A * Tracked at: https://dev.launchpad.net/Bugs/BugQ%26A * Rationale: Vast majority of bug reports filed are low quality. The Bug Q&A concept would guide reporters to produce better, more actionable bug reports, thereby reducing the time required by a developer to figure them out; this translates into more bugs fixed per developer hour. * Status: * Is included on Roadmap - '''https://dev.launchpad.net/VersionFourDotO/Stories''' |
Line 97: | Line 66: |
1. Hiding comments or removing comments * Requested by: kernel team * Rationale: Bug reports have a tendency to accumulate a lot of inane/irrelevant/insulting comments. When asking an upstream developer to look at a bug report, we'd like to "clean up" the report to display only relevant, useful information. 1. Structured bug json data field(s) * Rationale: Currently Apport stores a lot of key:value data into bug descriptions. This is important and useful information but tends to clutter the bug report, can be hard for developers to review, and is error prone for other tools to parse and use. Being able to load this information into some sort of structured storage field (e.g. JSON) 1. PPA improvements. Build status notification. Ability to host multiple versions of a given package (e.g. for bisection study purposes). Expose more of the internal API through the external Launchpad API. 1. Soyuz archive index * Tracked at: '''https://dev.launchpad.net/ArchiveIndex''' * Rationale: Req'd by Software Center 1. Bug Bookmarking * Tracked at https://bugs.launchpad.net/bugs/193585 * Status: Needs escalation to Launchpad 1. Blueprints improvements: * Much work needed: 65922, 115158, 120942, 125377, 126522, 137397, 172532, 177519, 177520, 247672, 307495, 398604, 398605, 489288, 825523 * Status: Has been proposed to merge blueprints and bugs? * If this work is schedule we need to understand how existing use cases will be transitioned. Need guidance and a plan. 1. Task tracking * Rationale: We currently have makeshift task workflows littered throughout launchpad: Workflow tags, blueprint work-items, archive team subscriptions, kernel team abusing bug tasks, merge review requests, sync requests, etc. We need something that is more systematic, unified, coherent, and * Tracked at: Bug:393117, Bug:578263, [[https://dev.launchpad.net/VersionFourDotO/OutOfScope/Blueprints|Blueprint decomposition]] == Low priority == 1. Answers needs either significantly improved, or scrapped in favor of just using AskUbuntu.com. Need guidance and a plan. 1. Prohibit filing bugs on obsolete packages (Bug:46385) 1. Opening a new distrorelease before releasing the previous one (shortcoming relative to former dak infrastructure) * Tracked at: '''https://bugs.launchpad.net/soyuz/+bug/87012''' * Rationale: When opening a new distrorelease, uploads must be temporarily blocked until the toolchain and other basic infrastructure are in place. Opening the new release early would allow this work to happen in parallel, so that the new release would be immediately open for development. * Status: * PPAs make it possible to do some of the preparatory work for a new distro series * Fully handling this was not targeted for Launchpad 4.0 |
|
Line 104: | Line 113: |
1. Package version tracking for bugs (shortcoming of Launchpad relative to debbugs) * Not targeted in Launchpad 2.0 |
1. Search PPAs for version of app you want, for version of ubuntu you're on 1. A way to mark bugs as fixed (no longer in progress), but waiting for a merge (not yet fix committed) 1. Ability to clone or split a bug report, when a user has reported multiple problems that each need tracked separately 1. Search across attachments * From previous discussion, sounds like this would be quite hard / resource intense 1. Tarball visibility / navigation 1. Add a "workaround" field to bug (Bug:54652). (Already escalated by Corp Services) 1. Launchpad doesn't support multiple attachment (Bug:82652). (Already escalated by Corp Services) == Undefined == == Other stakeholder issues also relevant to Ubuntu: == See also: Launchpad's RoadMap and list of [[LEP|LEPs]]. |
This page discusses ways Launchpad could better serve the Ubuntu community. Please contact us with thoughts or questions. |
Launchpad contact |
|
Ubuntu contact |
High Priority
- Semi-automatic bug forwarding to upstream bug trackers
Tracked at: ???
- Rationale: Ubuntu receives a very high volume of bug reports which should be forwarded upstream. Making this process more efficient would improve both the quality of Ubuntu and its relationships with upstream projects.
- Status: Some of the steps for this to happen are implemented. Additional work includes:
The "no upstream bug tracker exists" use case, which is described in https://blueprints.launchpad.net/malone/+spec/forwarding-to-email-address (Done?)
- Comment synching to enable inter-bug-tracker replies (Done?)
Map remote bugtracker product/component to source package: https://dev.launchpad.net/LEP/BugzillaComponents (Nearly done)
Forwarding of selected attachments from LP bug to upstream - https://dev.launchpad.net/LEP/ForwardAttachmentsUpstream
- Automatic user registration in remote tracker
- Automatic fill-in of upstream bug report fields (title, description, priority, cc, etc.)
- Only Series Tasks
- Tracked at:
20111103 - https://blueprints.launchpad.net/ubuntu/+spec/other-p-bugtaskseries
- Bugs 314432, 777861, ...
- Rationale: Many times bugs are specific to a particular version of Ubuntu, but this is not tracked by Launchpad. We work around this by tagging bugs with the release codename but this is done inconsistently (apport will include the tag automatically, but non-apport filed bugs don't). There are various bugs, features, and usability issues for which being able to segregate bugs by series would be a possible solution.
- Status: ??? (I've heard it's proposed but not yet on the schedule.)
- Tracked at:
- Temporarily adding the uploader as a bug contact for the package being uploaded
- Tracked: ??
- Rationale: Our development model is such that packages are often uploaded by a developer who has no ongoing relationship with the package. Because they do not receive bug reports for the package, it is easy for them to be unaware of having introduced a regression.
- Status:
- git support. Native git hosting.
- Tracked: ??
- Rationale: While bzr is awesome, many projects use git instead. Launchpad's utility to the broader community would thus be improved if it was able to host git-based projects.
- Wiki support integrated throughout Launchpad.
Tracked: 240067, 254167, 797331, Wiki markup in blueprints
- Rationale: We need wiki-like markup (including tables), revision tracking, and easy cross-linking to other LP entities so we can display information to users more clearly and orderly, and to keep track of changes made to our pages. E.g. PPA descriptions, project home/about pages, blueprints, whiteboards, etc.
- QA status/workflow tracking.
- Tracked: ??
- Rationale: Testing and quality control are becoming increasingly important to Ubuntu, yet Launchpad provides little in the way of built-in QA tracking supports.
- Need ways to better flag bugs/branches/patches/etc. as needing testing, passed testing, failed testing, and so on. Ideally should also support hooking into automated testing in some fashion, with the goal of being able to delineate between code ready to be released from that needing additional work.
Medium Priority
- Package version tracking for bugs (shortcoming of Launchpad relative to debbugs)
- Rationale: Some bugs are particular to a specific version of a given package, or are fixes as of a given version. Currently Launchpad doesn't track this so we have to ask for this info every time a bug is filed. If it's filed with apport this generally will attach the info automatically, but many bugs aren't filed with apport.
Bug Q&A
Tracked at: https://dev.launchpad.net/Bugs/BugQ%26A
Rationale: Vast majority of bug reports filed are low quality. The Bug Q&A concept would guide reporters to produce better, more actionable bug reports, thereby reducing the time required by a developer to figure them out; this translates into more bugs fixed per developer hour.
- Status:
Is included on Roadmap - https://dev.launchpad.net/VersionFourDotO/Stories
- Visual distinction between bug comments from authoritative Ubuntu people and bug comments from random Launchpad users
Tracked at: ???
- Rationale: Users who view and file bugs in Launchpad are not always familiar with the way bug tracking works in a large community project like Ubuntu. When they receive a comment which is inappropriate, erroneous or poorly presented, they assume that it came from someone representing the project, when in fact anyone with an email address can post a response. Users who find these bugs via web searches have difficulty telling the difference between comments from users and authoritative information from developers and QA. We want to avoid this confusion and misrepresentation, while still allowing everyone to participate, by visually showing the user whether the commenter is a member of an official team (such as Ubuntu QA), perhaps by showing the team badge next to their name.
- Status:
original bug at https://bugs.launchpad.net/malone/+bug/81692
https://blueprints.launchpad.net/launchpad-registry/+spec/official-project-members covers this for Bugs and Answers
Launchpad claims this specification is related to the bug: https://blueprints.launchpad.net/launchpad-foundations/+spec/person-name-presentation
- Not targeted in Launchpad 4.0
- Hiding comments or removing comments
- Requested by: kernel team
- Rationale: Bug reports have a tendency to accumulate a lot of inane/irrelevant/insulting comments. When asking an upstream developer to look at a bug report, we'd like to "clean up" the report to display only relevant, useful information.
- Structured bug json data field(s)
- Rationale: Currently Apport stores a lot of key:value data into bug descriptions. This is important and useful information but tends to clutter the bug report, can be hard for developers to review, and is error prone for other tools to parse and use. Being able to load this information into some sort of structured storage field (e.g. JSON)
- PPA improvements. Build status notification. Ability to host multiple versions of a given package (e.g. for bisection study purposes). Expose more of the internal API through the external Launchpad API.
- Soyuz archive index
Tracked at: https://dev.launchpad.net/ArchiveIndex
- Rationale: Req'd by Software Center
- Bug Bookmarking
Tracked at https://bugs.launchpad.net/bugs/193585
- Status: Needs escalation to Launchpad
- Blueprints improvements:
- Much work needed: 65922, 115158, 120942, 125377, 126522, 137397, 172532, 177519, 177520, 247672, 307495, 398604, 398605, 489288, 825523
- Status: Has been proposed to merge blueprints and bugs?
- If this work is schedule we need to understand how existing use cases will be transitioned. Need guidance and a plan.
- Task tracking
- Rationale: We currently have makeshift task workflows littered throughout launchpad: Workflow tags, blueprint work-items, archive team subscriptions, kernel team abusing bug tasks, merge review requests, sync requests, etc. We need something that is more systematic, unified, coherent, and
Tracked at: 393117, 578263, Blueprint decomposition
Low priority
Answers needs either significantly improved, or scrapped in favor of just using AskUbuntu.com. Need guidance and a plan.
Prohibit filing bugs on obsolete packages (46385)
- Opening a new distrorelease before releasing the previous one (shortcoming relative to former dak infrastructure)
Tracked at: https://bugs.launchpad.net/soyuz/+bug/87012
- Rationale: When opening a new distrorelease, uploads must be temporarily blocked until the toolchain and other basic infrastructure are in place. Opening the new release early would allow this work to happen in parallel, so that the new release would be immediately open for development.
- Status:
- PPAs make it possible to do some of the preparatory work for a new distro series
- Fully handling this was not targeted for Launchpad 4.0
- Notifying the release team of new milestone targets
Tracked at: ???
- Rationale: The release team tracks outstanding targets for milestones and their resolution. However, they currently must poll in order to obtain this information. Asynchronous notification would be more efficient.
- Status:
- Structural subscriptions were targeted for Launchpad 2.0 (2009-08-03: update, anyone? Do we push notification now?)
- Search PPAs for version of app you want, for version of ubuntu you're on
- A way to mark bugs as fixed (no longer in progress), but waiting for a merge (not yet fix committed)
- Ability to clone or split a bug report, when a user has reported multiple problems that each need tracked separately
- Search across attachments
- From previous discussion, sounds like this would be quite hard / resource intense
- Tarball visibility / navigation
Add a "workaround" field to bug (54652). (Already escalated by Corp Services)
Launchpad doesn't support multiple attachment (82652). (Already escalated by Corp Services)
Undefined