Launchpad Entry: ubuntutheproject-soyuz-n-archivereorg-component-preparation
Contributors: Emmet Hikory
Packages affected: Soyuz
Clearly identify outstanding work to be done in Soyuz to prepare for reorganisation of components, and discuss effort requirements with the Soyuz team. Some inital items might include:
- MOTU upload permission (able to upload to packages not included in a packageset)
- Providing a means to define packageset layering
- refactoring ogre-model to use packageset layering rather than components
- wider UI exposure of packagesets
Packagesets are now fully supported in Soyuz, including upload permissions and build environments, with clear information presented in the UI.
With the introduction of packageset-based upload permissions, an increasing number of developers are unsure which packages they can upload, or how uploading those packages may affect others. With a few enhancements to Soyuz, we should be able to provide accurate answers to these questions using common tools.
- Alice is a MOTU who wishes to make an upload during a freeze. She checks the package overview page on Launchpad, confirms the package belongs to no packagesets, and uploads.
- Bob is a flavour developer who wants to ensure a package is not available on the buildd whilst building any packages for his flavour. He checks the package overview page on Launchpad and compares agains the packageset layering documentation to determine why the package is present. He notices it is in the packageset for his flavour, and adjusts the seeds to remove it.
- Chris is an upstream developer who wants to understand how their software is used in Ubuntu. Collecting information from Launchpad, it can be determined that the package is used in several flavours, but only as a build-dependency.
- Dora is an archive administrator who wants to know whether to approve a sync request. She checks the package overview page for the package and the groups to which the developer belongs to verify the developer can upload to the package, and then approves the sync request.
- Everett is a release manager who needs to know which flavours will require a respin for a library upload. He checks wihch packagesets contain the package, and consults the ogre-model to determine which flavours may build packages based on this library.
- Francis is on the SRU verification team and needs to understand the environments in which a proposed upload should be tested to complete verification. By checking the affected packagesets, Francis is able to test in each affected flavour before approving the SRU.
- Georgia is a flavour developer who wants to know whether sponsorship is required for a certain upload. She checks the contents of her packageset and discovers her package is not present. She submits a request to the sponsor queue.
- Packagesets are well defined in the launchpad data model
- Implementation of ogre-model changes will not significantly affect the set of packages available for any current builds
- Any developers who would lose the ability to upload one or more packages would be welcome to join relevant flavour teams
Additional tests shall be defined in the launchpad test suite to cover the following conditions:
- MOTU uploading to package in a packageset (should fail)
- Packageset uploader uploading to package in correct packageset (should pass)
- Package Overview showing correct list of packagesets
- Installation of a package excluded by the ogre-model during a build
- Use of Main/Universe support issues.
- Use of Main/Universe for security uploads.
- Social issues related to ArchiveReorganisation/Components
- Mirroring concerns related to ArchiveReorganisation/Components
- Adjustments to ubuntu-dev-tools, ubuntu-archive-tools, ubuntu-qa-tools, software-centre, synaptic, muon, etc. to reflect the changes.
BoF agenda and discussion
Remember: 15 minutes per topic, or we run out of time.
MOTU Upload Permissions
- Allow upload to anything not in a packageset
- Disallow upload to anything in a packageset
- Data Model changes
- Code Changes
Dealing with PerPackageUpload arrangements
- Need to define each packageset as depending on other packagesets
- Use of STRUCTURE
- Data Model
- Exposure of data (API only?)
- Any build must not be able to install build-dependencies external to the packagesets for the software being built or underlaying packagesets
- Each package must have a defined set of packagesets against which it builds
- Handling packages in more than one packageset
- Enforcing installtion failures
- Handling layered packagesets gracefully
UI Exposure of packagesets
- Should appear on package overview pages
- Should appear in more queue pages
Should be used for acls for things like nominations (LP: #507773)
- Other places to display
- Issues with display
- Handling layering and inclusion in multiple packagesets