Soyuz User Stories

This section contains the story cards for the Launchpad Soyuz team. Completed stories are moved to the VersionThreeDotO/Soyuz/StoryCardsArchive. Priorities are found on the main page.

Multiple PPAs per user

Story Points: xxx

• As a PPA owner,
  I'd want to activate an extra PPA,
  so I can build and publish nightly-tarballs of a unstable source for a different audience;

  As a launchpad user,
  I want to view all the PPAs related to a specific user on his page,
  so I can decide which one I am interested in.

  As a soyuz developer,
  I should be able to control the repository quota for all repositories owned by the same person,
  so source uploads can be rejected when they exceed a pre-defined value.
  (very bogus and unfeasible, can't we continue with per-PPA quota ?)

  As a Launchpad administrator,
  I want to see how much space in the PPA machine is used by a specific group of users,
  so I can judge whether it's fair and possible to allow them to use more.

UI for build dependency work

Story Points: 5

• As someone who is interested in rebuild archives,
  I want to go to a Launchpad page,
  so I can see at a glance which packages built and which did not,
  and optionally rebuild failed builds.

API manipulation of PPAs

Story Points: 13

• As a PPA owner and/or user,
  I want to use the webservice,
  so I can copy, delete, rebuild and gather information about packages in the PPA.

Notes:

• bug 276020

Package Sync Reviews

Story Points: 13

XXX

Complete Private PPAs

Story Points: 20

• As a PPA owner,
  I want to set Apache access control on the published repository,
  so that I can control who is allowed to download from a private PPA.

Slave Scanner Next Generation

Story Points: xxx

• As someone who uploads or uses packages in Soyuz,
  I want the slave scanner to parallelise access the the slave builders,
  so that the build farm is utilised to its maximum capacity, thereby speeding up builds.

Support for handling debug symbol uploads in virtual buildds

Story Points: 8

• As a soyuz developer,
  I want to control debug-symbol generation via a lp-buildd dispatch API flag,
  so they can be enabled/disabled according the features we provide in Launchpad;

  As a soyuz developer,
  I want to receive ddebs as part of the build results when this feature is enabled (listed in the result filelist and as part of the changesfile),
  so they can be processed and stored accordingly.

API/UI to unembargo security package

Story Points: 8

• As a member of the Ubuntu Security Team,
  I want to use an API tool to unembargo packages from the private PPA into Ubuntu,
  so that shell access to cocoplum is not required

Soyuz Distribution Script

Story Points: 3

• As a launchpad developer,
  I want to convert the shell script (that publishes Ubuntu hourly) to a Python script,
  so that it's easier to maintain, reports errors properly and allows distro-team hooks.

Licensing Metadata support

Story Points: 2

• As an Ubuntu developer,
  I would like to see a packages licensing metadata in a structured format,
  so that it can be easily machine parsed.

Support PDiff

Story Points: XXX

• As an Ubuntu user,
  I want apt-get update to support the pdiff format,
  so that it minimises the data I need to download.

Support build and publication of ddebs

Story Points: 8

• As a packager,
  I want to Soyuz to handle debug debs,
  so that Soyuz can publish them in the archive.

  As a ubuntu user,
  I want to have a separate repository for publishing debug-symbol debs,
  so users can enable it for browsing and installing debug-symbols via synaptic;

  As a PPA owner,
  I want to optionally build and publish debug-symbol binaries for my sources within the context PPA,
  so users can browse in install them if necessary; (I'm aware it will eat bits of my quota)

Pooling of builders

Story Points: 3

• As a build farm administrator,
  I want to be able to pool all the builders,
  so that they can be shared by PPA and distro builds.

Any architecture builders

Story Points: 13

• As a build farm administrator,
  I want the Soyuz buildmaster to handle builders that can build any architecture,
  so that the build farm is more efficient.

PPA diffs against Ubuntu

Story Points: 5

• As a PPA user,
  I would like to see my packages diffed against corresponding Ubuntu packages,
  so that he can tell what would happen if he were to copy that package from the PPA straight into Ubuntu.

Multi-series support in package uploads

Story Points: 8

• As a package uploader,
  I want Soyuz to handle specifying multiple distroseries in the changes file,
  so that package uploads are targeted to more than one series in a single upload.

Show complete changelogs

Story Points: 5

• As a Launchpad user,
  I want to see a /ubuntu/+source/<pkg>/+changelog page,
  so that it's easier to see the complete changelog in one place instead of piecing it together from individual SPR pages.

Show available PPA packages on Ubuntu package pages

Story Points: 5

• As a Launchpad user,
  I want to see a list of available PPA packages when browsing Ubuntu package pages,
  so that I can see if there's a more recent or better version available in a PPA.

Show a PPA 'heat' page

Story Points: 5

• As a Launchpad user,
  I would like to see a page showing emergent PPA 'heat' based on factors such as downloads, subscribers and karma,
  so that it's easy to see which PPAs are the most popular.

Soyuz Instant Messenger Buddy

Story Points: XXX

• As a Launchpad user,
  I would like to have a Soyuz buddy on my XMPP instant messenger list, so that I get notifications of important events like build failures and uploads.

Karma for uploads

Story Points: 2

• As an Ubuntu packager,
  I would like to receive karma for uploading packages,
  so that I am recognised for my efforts.

Package Layer ACL

Story Points: XXX

• As someone who manages a distribution,
  I want to have ACLs controlling upload access by "Package Layers",
  so that permissioning by component is no longer necessary.

Notes:

1. Persons in the Ubuntu-dev-generalists group may upload anywhere. However, uploads to an exclusive specialist package layer will be queued for review.
2. Persons in the Ubuntu-dev-generalists-apprentices group may upload anywhere. However, their uploads will always be queued for review.
3. In case of non-exclusive specialist package layers the designated persons (i.e. the specialists) as well as Ubuntu-dev-generalists may upload without review.
4. In case of *exclusive* specialist package layers only the designated persons can upload directly, all others get queued for review.