Please backport cockpit 138-1 and future versions from devel
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Xenial Backports |
Fix Released
|
Undecided
|
Martin Pitt | ||
Yakkety Backports |
Fix Released
|
Undecided
|
Martin Pitt | ||
Zesty Backports |
Fix Released
|
Undecided
|
Martin Pitt |
Bug Description
I would like to request a general approval to backport the current development series of https:/
Reason
======
http://
Current Ubuntu Cockpit users consume it from https:/
See https:/
Testing
=======
Upstream has a very comprehensive unit and integration test suite; the latter runs on lots of OSes, amongst them are Ubuntu 16.04 LTS, Debian 8 (Jessie) and Debian testing. (Example: https:/
Reverse dependencies
=======
Cockpit is (currently) a leaf project without reverse dependencies. In the future the intention is that various services can ship/provide their own Cockpit module to integrate into the web UI. There is a stable module interface and communication protocol, but there are no current plans yet how to do CI across these project boundaries. Once that becomes an issue, this will be discussed upstream. Presumably this will involve the usual automatic reverse dependency autopkgtesting that we do for all packages in Ubuntu.
Process
=======
The cockpit package as in Ubuntu zesty and devel backport and work without any changes on Ubuntu 16.04; just "backportpackage" is sufficient. I would like to handle this myself (uploading and queue processing), but I'd like to get a formal ack on this first.
Martin, please go ahead with this. Until you're added to backporters, ping me or someone else for queue accept. (Or if you're still in ubuntu-archive, JFDI.)
I'm happy for you to do this in future without paperwork, as long as each upload is smoke tested (b/i/r) before pushing.
We don't have autopkgtest hooked up for -backports at the minute. That might be an interesting feature to work on. In the meantime, if your package has them, you can trigger it manually from a PPA and then link the results into this bug report for reference.
One thing is that backports policy requires the upgrade path to be maintained. At the minute, that means that z -> x backports need to go to y too.