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 be able to define a package set and associate it with source and binary package names.

• As someone who manages a distribution,
  I want to be able to specify upload permissions (may upload, may upload subject to review) for a given package set and a person/team.

• As someone who manages a distribution,
  I want to be able to define hierarchical relationships between package sets i.e. include package sets into other package sets and remove them respectively.

• As someone who manages a distribution,
  I want to be able to change the value of the "specialized" flag on a package set (this has no bearing on the binary package name associations).

• As a launchpad user,
  I want to be able to see the package set inclusion hierarchy.

• As a launchpad user,
  I want to be able to see a filtered list of (source/binary) package names for a given package set.

• As a launchpad user,
  I want to be able to see details for a given package set P and a (filtered) list of package names e.g. how did a package name N get included in P (in case of package subset relationships: all inclusion paths for N), "specialized" flags for source package names etc.

• As a Soyuz developer,
  I need to be able to formulate/run an inexpensive query that tells me whether a package is in any specialized package set.

Pertinent comments by cjwatson

1. there will be exactly one package set with generalist members, and that package set will be equal to the entire Ubuntu archive.
2. what we probably actually want here is a set of generalist permissions attached to Ubuntu, and some number of package sets with specialist permissions attached to them.
3. if package X is a member of package sets A, B, C, and D where C and D are exclusive, then the set of valid uploaders is the union of those with permission to upload to C or D.
4. if package X is a member of package sets A, B, C, and D, none of which are exclusive, then the set of valid uploaders is the union of the generalists with permission to upload to Ubuntu as a whole together with those with permission to upload to any of A, B, C, or D.
5. package sets probably need to contain both source and binary packages in order to work properly, although upload permissions would only be calculated based on source packages.
6. the most general solution would be that each package set would have two sets of permissions associated with it: "may upload unconditionally" and "may upload subject to review".
7. Re. package layer hierarchies:
   • question: Once a package layer R is created and owned by a person or team T: what packages are they allowed to add to R? What other (nested) layers may be added to R?
   • answer: They may add whatever packages they like. I do not expect that they would be able to create further package sets freely, or indeed that they would need to do this very often.
8. Re. "specialized" package sets:
   • question: What are the rules in a case where layers P and Q e.g. have a shared package X and now Q is to be made exclusive but the owners of P and Q differ?
   • answer: Exclusive sets win, by definition; the TB will mediate if necessary.