Ubuntu/InfrastructureNeeds/Archive

Not logged in - Log In / Register

Done!

  1. Filing of bug reports with package metadata (cloakroom)
  2. Copying of source and binaries between pockets (shortcoming relative to former dak infrastructure)

    • Rationale: Currently, packages are built and tested in -proposed, then re-uploaded to -updates, rebuilt and released to users. This process does not allow for the final build to be tested before being released to users, allowing the possibility of unexpected regressions after testing, and with large packages introduces an unnecessary build delay and mirror push. Additionally, this capability would allow packages to be copied from -security to -updates, allowing them to be mirrored and saving a substantial amount of archive bandwidth.

    • Specified in LaunchpadWiki:Soyuz/NativeSourceSyncing (TODO: move that spec here, or remove this item if we're not going to do it)

  3. Automatic closing of bugs via upload (shortcoming relative to Debian's infrastructure)
    • Rationale: Each bug must currently be closed manually in Launchpad after making an upload. Bug numbers are automatically extracted from changelogs and included in the .changes file, and making use of that information in Launchpad would avoid all of these manual steps. Debian has had such a feature since sometime in the 1990s and its developers generally consider this a useful invention.
    • Status: .changes already include a structured text field containing the list of bugs to close. What is needed is for this information to be acted upon by Launchpad.
  4. Shorter turnaround for translating a new release
    • Rationale: Ubuntu 6.10 was not translatable until about 8 weeks prior to its release. Ubuntu 7.04 was not translatable until 5 weeks prior to its release. This does not leave enough time for Ubuntu to be well translated, and causes problems for upstreams attempting to translate in Launchpad (including frustrating bug reports about missing/incorrect Ubuntu translations).
    • Status: Ubuntu 7.10 translations opened 18 weeks in advance of release!
  5. Modeling Ubuntu bug workflow in Malone
    • Rationale: The bug workflow employed in Ubuntu is not easily modeled in Malone, and the workflow used in Malone doesn't fit all of the needs of Ubuntu development. We believe that a small number of changes could make a big difference in closing this gap.

    • Specified in UbuntuWiki:BugWorkflow

  6. Bug tracking for commercial repository (bug 58495)

    • Rationale: Currently, bugs in packages distributed in the commercial repository cannot be properly filed in Launchpad because the packages are not included in the Launchpad database. This is because this repository is managed outside of Launchpad, by a dak instance.
    • Ideas:
      • Create a new 'commercial' component in Launchpad

      • Import package data from -commercial using gina

      • Manage -commercial in Launchpad entirely, using a PPA(?)

  7. Building unpublished source (shortcoming relative to former dak infrastructure)
    • Rationale: Source packages currently require at least two publisher runs in order to be published, because the source must be published before it can be built. There is no inherent reason for this, and critical fixes would be ready faster (especially near releases).

    • Specified in LaunchpadWiki:BuildUnpublishedSources

    • https://bugs.launchpad.net/soyuz/+bug/77853

  8. Web interface for Soyuz upload queue processing
    • Rationale: Processing upload queues currently requires privileged shell access to the production archive. The security implications of this (unrestricted write access to the archive) mean that we cannot effectively distribute certain tasks beyond distro team staff: for instance, we cannot delegate management of uploads to the universe and multiverse components to members of the community. This causes extra work and delays near release times.
    • Status:

      • A web interface to the queues is already partly in place, and it is possible to inspect uploads (although not as conveniently as it could be; see the package-diff item below).

      • It is not possible to override packages. Archive administrators without privileged shell access can now process the NEW queue to some degree by taking advantage of default component mappings. However, if any changes to the default overrides provided are required, a privileged administrator still needs to step in. A UI for overrides needs to be designed.
      • Targeted for Launchpad 2.0
  9. Automatic diffs of new uploads, relative to the version being superseded
  10. Security updates in Launchpad (shortcoming relative to former dak infrastructure)
    • Rationale: Security updates are currently processed and built by a dak instance, then hand-fed into Launchpad through a manual process. This requires maintaining redundant infrastructure and limits developer participation.

    • Specified in LaunchpadWiki:Soyuz/SecurityPocketSupport

    • Status
      • Will be done by the end of 2007 (Kiko)
      • Targeted for Launchpad 2.0
  11. Package-specific hints for reporting a bug

    • Rationale: Many packages have associated written instructions in the wiki which explain how to debug problems, which are valuable to bug reporters and triagers. However, there is no link from Launchpad to this information, so it is only used when the user has prior knowledge of it. For triagers, this means an extra round-trip to ask the user to read the document and follow its instructions. Launchpad should contain a simple (1 paragraph) hint for a category of packages (desktop, xorg, kernel) and an optional link to the wiki page.

    • https://bugs.launchpad.net/malone/+bug/43893

    • Status:
  12. Support for attaching apport data to an existing bug
    • Rationale: Most bugs are reported directly to Launchpad, and so do not benefit from the automatic submission of system data to Launchpad. Some bugs are not reported from the system where the bug was observed (e.g., on servers).
    • Status:

      • Filed as bug 85040, 124338

      • Was under consideration for Launchpad 2.0. Was it done?
      • Could be implemented by the distro given good APIs for Malone.
  13. 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
  14. Web interface for syncing source packages in Soyuz, accessible to those with corresponding upload privileges

    • Tracked at: https://bugs.launchpad.net/launchpad/+bug/771341

    • 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: All items are marked finished or obsolete
  15. 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 rewrite of the activity log.

  16. 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.
        • 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.
        • Marked as completed by Curtis Hovey 2010-05-31
    • 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

Ubuntu/InfrastructureNeeds/Archive (last edited 2011-10-13 01:39:39 by bryce)