<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hello. Back in November 2018 [1] and subsequent requests since [2] [3], I made several attempts to reach out to the Backports team on public lists to volunteer my time and energy to work on the Backports queue and to clear them out, and to get more information on what the team requires for someone to help with the backports process. With no public responses to my messages, the third message [3] I sent included direct messages to the admins. I had received only one response off-list, and it was suggested through there that: 1. The backports process in general is broken. 2. Putting the burden on a tiny number of admins to do checking and uploading does not scale to the volume of requests 3. Given points #1 and #2 my request to assist was not likely to be actioned on. It was also stated that because the current process is broken, it no longer is capable of being considered a valid approach to backports. In ongoing research into all backport requests currently in the queue including for now-EOL releases (bugs in the Backports targets projects that have yet to be closed or acted on at all), I have come to the following conclusions: 1. That the current process is indeed broken for Backports, concurring with the private opinions provided to me. (With some smaller exceptions for certain packages, such as cockpit as an example, where developers directly handle their own requests.) 2. That the current process for backporting things is not feasible for scaling, also concurring with the private opinions provided to me. 3. That the vast overwhelming majority of backports requests are made by mostly 'random users' or users who are not 100% familiar with requirements for backporting or package versions to be included (including build and testing requirements). 4. That the vast majority of requests do not have ample justifications tied to them other than "I want this version available" In separate discussions with interested parties and DMB members off-list and in IRC discussions privately, it was suggested that if the current process is broken, we need to redesign it. I am proposing that we change the process and how it's handled in a substantial way, redefining the requirements for Backports and the process to be more efficient. This proposal makes some key changes to the processes, in that: 1. It moves uploading of backports from the small backporters team to the larger developer body, and removes entirely the "Please backport xxx" class of requests. 2. It will retain the Backporters team's ability to review backports, and ultimately approve backports so they can be moved from the Upload queue into the specific repositories, in a manner similar to how the SRU team processes the SRU queue, but further restricts the requirements to require dedicated Ubuntu Developer (Team or Individual) backing. 3. This retains the Backporters' privilege of review before releasing things into the -backports repository, in a manner similar to how SRUs would behave. (This might require some retooling behind the scenes for the upload queue though...) While this proposal changes how things're delegated and handled, this also handles the problem of "too many requests" - if a request can only move forward with an individual or team backing it and they're an established developer, that solves many of the problems that the current system has shown. This also means that the number of things that needs actual approval from the Backports team is limited, as well as the fact that the 'random backport request' won't go through if it's otherwise not getting support from an established developer. Please also note that while this proposal touches base on how I would envision the process to operate, I welcome *all opinions and refinements to this proposal and process*, as I intend this to only be the 'beginning' of a more refined proposal or process declaration for changing the Backports process. The following is my proposal in detail: Backporting Requirements ------------------------ The uploading of backports is now to be performed by Ubuntu developers. The ~motu team can upload any backport, and we will request the DMB to extend PPU rights to apply to all backports pockets too. 1) Developers file requests in the regular Ubuntu project, try their best to ensure that the backport is good (build/install/run test, post in the bug confirming this has been done), and upload it to the queue. The "Continued Functionality of Reverse-Dependencies" requirement from [0] is to be relaxed. Each and every reverse dependency need not be tested; the uploader should use their judgement, which the backports team will need to concur with. This requirement has been responsbile for making it practically impossible to backport anything complex. 1.5) People who need sponsoring can perform step 1) and subscribe ~ubuntu-sponsors *once there is a debdiff/package on the bug to upload*. 2) The ~ubuntu-backporters team reviews uploads from the queue and accepts/rejects, in much the same way as the SRU team does currently. 3) Any changes to the package which are required for backporting must be minor in nature or otherwise required, and will be reviewed specifically by the Backporters Team prior to backport acceptance. 4) A backport request must specify the SOURCE release to backport a package from and the TARGET release being backpoted to. 5) Both SOURCE and TARGET releases must be a currently-supported release of Ubuntu. Requests to backport to or from EOL releases will be rejected. ------ An additional point of discussion is that if we can remove 'random end user requesting' from the equation, that would also lighten up the backports queues. When an end user wants to make a request, they should field the request via <a class="moz-txt-link-abbreviated" href="mailto:ubuntu-backports@lists.ubuntu.com">ubuntu-backports@lists.ubuntu.com</a> or a similar mailing list for community input on the request; if a developer or sponsor wants to assist for that request, then with the revisions to the process above, the backport process can move forward without major impact to the queue and without adding additional major stressors to the Backporters team, as those with upload rights would already be able to do the 'upload' steps. ------ Opinions, alterations, recommendations, changes, etc. are all welcome, as I stated I intend this to more or less spark further discussion rather than be accepted currently verbatim. I hope that this will ultimately lead to improving the Backports process, as it currently is defunct for the most part and does not (and as it currently is, will not) be able to continue to process new Backport requests without radical changes to the process. (Note that parts of this proposal have had contributions from Iain Lane, Robie Basak, and Seth Arnold, at my request, prior to my submitting this, in order to better phrase and construct this proposal in an acceptable manner.) ------ Thomas Ward Ubuntu Server Team Member LP: ~teward [0]: <a class="moz-txt-link-freetext" href="https://wiki.ubuntu.com/UbuntuBackports#Continued_Functionality_of_Reverse-Dependencies">https://wiki.ubuntu.com/UbuntuBackports#Continued_Functionality_of_Reverse-Dependencies</a> [1]: <a class="moz-txt-link-freetext" href="https://lists.ubuntu.com/archives/ubuntu-devel/2018-November/040549.html">https://lists.ubuntu.com/archives/ubuntu-devel/2018-November/040549.html</a> [2]: <a class="moz-txt-link-freetext" href="https://lists.ubuntu.com/archives/ubuntu-devel/2018-December/040563.html">https://lists.ubuntu.com/archives/ubuntu-devel/2018-December/040563.html</a> [3]: <a class="moz-txt-link-freetext" href="https://lists.ubuntu.com/archives/ubuntu-devel/2018-December/040569.html">https://lists.ubuntu.com/archives/ubuntu-devel/2018-December/040569.html</a> </body> </html>