Make proposed pocket useful for staging uploads
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Low
|
Colin Watson |
Bug Description
https:/
PPAs can serve this purpose to some extent. However, they have significant failings:
* They don't provide a single place where QA can run tests on everything pending integration. (The recent eglibc upload was staged in a PPA, which helped a bit but not enough.)
* There is no formal identification of some PPAs as more official than others, so they don't provide a good equivalent of a single "unstable" branch for users.
* While copying uploads from a PPA to the primary archive with included binaries is possible, it's somewhat scary and we prefer not to do it.
* Ubuntu developers who do not work for Canonical cannot use PPAs to stage uploads which will be copied including binaries, because they are not permitted to have access to non-virtualised PPAs.
In other words, PPAs are akin to unmerged branches in personal namespaces; we would like to create something that is more like the devel branch of Launchpad, which can have changes that have not been deployed to production.
We would like to use the existing -proposed pocket, which is used for staging uploads to -updates, for this purpose. There is no conflict between our current use of that pocket and this new use. Currently, it is only possible to upload to it when the distroseries is FROZEN or in one of the stable states. We would like it to additionally be possible to upload to it when the distroseries is in the other unstable states (DEVELOPMENT or EXPERIMENTAL). Furthermore, I think it would be helpful if uploads to -proposed were auto-approved in the same situations that cause uploads to the release pocket to be auto-approved. We're only intending to use this for a fairly small fraction of uploads to start with - the ones that are most damaging when they break, or that cause significant problems when built out of sync on different architectures - but we might well want to use it more widely in future and I don't want to impose a huge burden on archive administrators.
Obviously doing a full job of the staging-pocket idea will require much more work, including test systems, tools for checking soundness of dependencies, PQM/tarmac-like systems for automatically copying packages between pockets, and so on; but Launchpad already exposes all the interfaces necessary to do that. Our assessment is that making the -proposed pocket usable pre-release is the only change we actually need from Launchpad, and it seems like this should be a simple enough piece of work. Absent objections, I'm happy to do the work.
Related branches
- William Grant: Approve (code)
-
Diff: 1314 lines (+280/-378)11 files modifiedlib/lp/archiveuploader/tests/data/badformat-changes (+0/-40)
lib/lp/archiveuploader/tests/data/multiple-stanzas (+0/-60)
lib/lp/archiveuploader/tests/data/singular-stanza (+0/-31)
lib/lp/archiveuploader/tests/nascentupload-announcements.txt (+8/-12)
lib/lp/archiveuploader/tests/uploadpolicy.txt (+95/-77)
lib/lp/archiveuploader/uploadpolicy.py (+16/-10)
lib/lp/registry/doc/distroseries.txt (+10/-1)
lib/lp/registry/model/distroseries.py (+6/-2)
lib/lp/soyuz/adapters/copypolicy.py (+10/-5)
lib/lp/soyuz/adapters/tests/test_copypolicy.py (+43/-29)
lib/lp/soyuz/tests/test_archive.py (+92/-111)
Changed in launchpad: | |
status: | New → Triaged |
importance: | Undecided → Low |
Changed in launchpad: | |
status: | Triaged → In Progress |
assignee: | nobody → Colin Watson (cjwatson) |
Changed in launchpad: | |
status: | Fix Committed → Fix Released |
We had at least 4 or 5 times in the last three weeks where having this would have prevented rather major breakage. People kept coming to us because apt-get dist-upgrade wanted to remove skype (due to buildd arch desync of glibc, and again gcc-4.6), amd64 was uninstallable (due to the webkit i386 build hitting an "out of memory" condition), armel images breaking because compiz failing to build on armel (due to a new bug in kdelibs), etc.
Can this please be bumped higher than "low"? Thanks in advance!