= Soyuz User Stories = This section contains the [[http://www.agile-software-development.com/2008/04/writing-good-user-stories.html|story cards]] for the Launchpad Soyuz team. Completed stories are moved to the [[VersionThreeDotO/Soyuz/StoryCardsArchive]]. Priorities are found on the [[VersionThreeDotO/Soyuz|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:''' * [[https://bugs.launchpad.net/soyuz/+bug/276020|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//+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. <> == Third party email notification of PPA uploads == '''Story Points:''' 3 As a PPA owner,<
> I would like uploads to my PPA to be notified to another team via email,<
> so that they are aware of package changes in the PPA. Notes: Add a column to IArchive which is a FK to IPerson. <> == Allow arbitrary people to upload to a PPA == '''Story Points:''' 3 As the owner of a team that owns a PPA,<
> I want to set arbitrary upload ACLs,<
> so that people outside of the team can upload packages to the PPA. Notes: IArchive.canUpload() change to check APs + unit test. <> == Allow external PPA dependencies == '''Story Points:''' 3 As the owner of a PPA,<
> I want to use build dependencies that are not hosted in Launchpad,<
> so that I can migrate some of my builds to Launchpad PPAs Notes: https://bugs.edge.launchpad.net/bugs/391088 <> == Allow partner component package uploads to PPAs == '''Story Points:''' 0.5 As the maintainer of partner packages,<
> I want to be upload packages for the partner component to a PPA,<
> so that I don't have to modify them again before uploading to Ubuntu. Notes: Simply remove upload rejection, everything else will work. <> == Gnome help lang packs == '''Story Points:''' 5 As an Ubuntu maintainer,<
> I want to split Gnome help translations out of debs,<
> so that space on the installation CD can be reclaimed. Notes: * new custom upload of raw translation file * do we want an API or publish to disk? bigjools to talk to pitti * some buildd work from IS required <> == Package set 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<
> so that upload permissions can be granted at an appropriate level and build/runtime package dependencies can be captured. '''Story Points:''' XXX As someone who manages a distribution,<
> I want to be able to specify upload permissions (may upload (with or without the "explicit" flag set)) for a given package set and a person/team<
> so that every Ubuntu developer is empowered to contribute while avoiding package breakage and reducing administrative overhead. '''Story Points:''' XXX 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<
> so that upload permissions and/or dependencies between binary packages can be modelled as needed. '''Story Points:''' XXX As someone who manages a distribution,<
> I want to be able to set or change the value of the "explicit" flag on a (package set related) archive permission row<
> so that the circle of users who may upload (without being subject to review) can be limited to a designated group and widened respectively. '''Story Points:''' XXX As someone who manages a distribution,<
> I want to be able to see what packages a pair of package sets (P and Q) have in common i.e. the intersection of P and Q<
> so that I can better understand the repercussions of changing the sets in question or granting upload permissions for them. '''Story Points:''' XXX As someone who manages a distribution,<
> I want to be able to see how a pair of package sets (P and Q) differ in terms of associated packages i.e. the set of packages that are in P but not in Q<
> so that I can better understand the repercussions of changing the sets in question or granting upload permissions for them. '''Story Points:''' XXX As someone who manages a distribution,<
> I want to be able to see what packages are associated with a package set ''hierarchy'' i.e. with a package set P and all of P's descendants<
> so that I can better understand the repercussions of changing the sets in question or granting upload permissions for them. '''Story Points:''' XXX As a launchpad user,<
> I want to be able to see the package set inclusion hierarchy<
> so that I can study upload permission policies or binary package dependencies. '''Story Points:''' XXX As a launchpad user,<
> I want to be able to see a filtered list of (source/binary) package names for a given package set<
> so that I can study upload permission policies or binary package dependencies. '''Story Points:''' XXX 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), "explicit" flags for source package names etc.)<
> so that I can analyze/debug upload permission policies or binary package dependencies. '''Story Points:''' XXX As a Soyuz developer,<
> I need to be able to formulate/run an inexpensive query that tells me whether a user may upload a package (based on package set upload permissions) without being subject to review<
> so that I can enforce upload permission policies. '''Database schema related resources''' 1. [[https://pastebin.canonical.com/14444/|The database schema patch]] 1. [[https://pastebin.canonical.com/14446/|Example queries]] 1. [[https://pastebin.canonical.com/14441/|The play data]] '''Changes and updates''' 1. The flag that authorizes a specialist group of developers to upload to a package set ''without'' being subject to review is now called `explicit` and is an attribute of the `ArchivePermission` table. 1. The `ArchivePermission.explicit` flag is ignored for `component` and `sourcepackagename` level permissions. '''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. 1. 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. 1. 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. 1. 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. 1. 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. 1. 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". 1. re. package set hierarchies: * question: Once a package set R is created and owned by a person or team T: what packages are they allowed to add to R? What other (nested) package sets 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. 1. re. "specialized" package sets: * question: What are the rules in a case where package sets 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.