1) How the community requests backports The existing process of the community simply opening a LP bug to request a backport seems like a completely unmaintainable process that puts all the backport work on the backports team. There is no way our team of 3 people can actually perform the backporting work as well as reviewing and approving/rejecting backports.
I suggest we restrict our team's work to *only* reviewing packages backported to the -backports queues. All the rest of the work should be done by the stakeholder(s) for the backport. I believe this is similar to the ~ubuntu-sru team's role, to only review and approve/reject existing uploads. To be clear, I think it's fine for any one of us to actually upload something to the -backports queue if we do want to request a backport, but in that case we should let one of the other team members perform the review and accept it (I believe this is also similar to SRU process). 2) review of tooling, 'requestbackport' and 'backportpackage' The 'requestbackport' script will almost certainly need to be updated, at best, and more likely just removed in favor of a detailed process/template added to the public wiki page docs. I think the 'backportpackage' script will need review, and I'm concerned that we may have uploads generated from this tool with little or no actual investigation or pre-review by the requestor of the backport. In any case, one or more of us should review both these tools to see what changes we need to make to them, if they are even still usable/applicable. 3) What releases we backport to - only LTS or any/all? As the nature of backporting a new version of something to an older release implies that users have some reason for not being able to simply upgrade to the later Ubuntu release, I'd like to suggest restricting backports to only LTS releases. This would mean both that backports to interim releases would always be rejected, but also it would mean backports would not need to be backported to both an LTS release as well as following interim release(s) that are not yet EOL, which would likely just add more work for no reason. 4) Security updates On the community page, it says "When a package which has been backported receives a security update, the Ubuntu Backporters will make a best-effort attempt to update the backport" which I think we need to drop. I do not think our team should have any expectation at all of any kind of maintenance of any backport package we approve; any further updates to the backported package should come from the community, and our role should *only* be to approve or reject uploads to the -backports queues. 5) Cleaning up the docs on 'Using Backports' As this section in the wiki seems to have been written quite a while ago, I think it's safe to assume nobody is still running 11.10 or earlier. So we should be safe to clean up this section, removing all the reference to how to 'enable' backports. We may want to leave in the detail about how to change from the default 'manual install' to 'automatic install', but note that it's probably not a good idea to switch to 'automatic install' for all backports packages. 6) Additional restrictions on what packages are eligible I don't see anything in the wiki docs about any "excluded" packages, but I think we should add some explicitly ineligible packages. The obvious one is the kernel; there is no way we should accept a backport of any kernel into a previous release. It's far too complex, and the kernel team already offers HWE kernels. I also think we should restrict packages that are provided by the Ubuntu Cloud Archive. This list of packages probably would need to be defined a bit more clearly if we're going to make this a rule, but in general if we are restricting backports only to LTS releases, then newer packages in this area already are provided by the publicly-available UCA, which is fully maintained, unlike the -backports pocket. Finally, I'm very cautious about any packages that provide libraries; it's probably not reasonable to completely ban this, but the potential for breakage seems very high. -- ubuntu-backports mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
