Comment 76 for bug 1267393
Revision history for this message
| Alexis Bruemmer (alexis-bruemmer) wrote | #76 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Response to James' inquiries in comment #67:
* juju team: can you comment on the package breakdown? For items requiring further discussion, it might be worthwhile understanding how often you are updating the embedded package (useful for the SRU question, below)
On average 50% of the package dependencies change between minor release (for example there were 14 package dependency changes from 1.24 to 1.25)
* SRU team: juju-core already has a release exception. For packages that are being broken out that were formerly part of the juju-core package and that the juju team will now maintain, can those just be given a release exception?
Yes, those should also be given a release exception. Many of these are central to keeping ubuntu current with existing clouds. For Juju to actually work, if the dependent packages are being split out, every single one of them will need to be included in the release exception.
* Ubuntu Archive team: juju-core will likely need a PPU for members of the juju team when it goes to main. Can we extend the acl to include the packages that are being broken out that they are going to maintain?
Yes, to deliver a fix to juju core, we need to fix the dependencies at the same time. This will be done by the same person, so yes to extending the acls to those packages.
* MIR team: for the packages that are being broken out, I propose that they don't get extended MIR review, but rather simply the packaging review to make sure they are following the Go standards as outlined in the MIRteam document
Yes, agreed.
* juju team (/security team): the juju team has said that they would like coordination of security updates for juju-core and golang-*-dev packages for which they maintain. I propose the security team maintains a list of packages and when we triage a CVE against a package in that list, we file a bug for the juju team to fix, and sponsor their uploads (like for other Canonical upstreams). juju team-- does that address your concerns?
Yes, we will own fixing security bugs for juju, and dependent libraries that we control or can patch.