My apologies for a slower reply, been messing with my mail gateways and had to deal with that first.
I am not in disagreement with this.Minor comments on some aspects of your proposal below. On Mon, Jan 14, 2019 at 04:39:32PM -0500, Thomas Ward wrote: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.I suggest that it might be easier and cleaner to simply say "anyone who can upload a given package to the development release can also upload its backport", at least to start with. Assuming we can configure Launchpad to allow this.
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  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.Perhaps ask for it to be demonstrated working in some (driver-defined) PPA and tested from there? Then there'd be a nice progressive procedure to get a backport landed - so interested parties could be using a PPA before "graduating" the package to the official backports pocket. We might still need to use the backports project though, to avoid collisions with SRU bug tasks.
Driver-defined PPA is going to be a little trickier, I think, here, Robie.
Assuming you mean that it'd need uploaded to a 'proposed' PPA like the Security Team has for landing patches, then that'd be locked for uploads to just the Backporters team - we could sponsor/stage such uploads to the PPA, though, but then we're back where we currently started - too many things to upload, not enough manpower to drive it.
Even if I were driving this, it'd turn with burnout eventually.
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.I suggest that we discuss and then define specifically what aspects of the upload are the responsibility of the uploader and the backporter team isn't expected to review. If we agree to cut down on what the backporter team has to check, then hopefully that will help with velocity.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.I suggest we define how to communicate these aspects with the backporters team, so they don't have to rediscover the changes by a potentially more time consuming review.
This can be a requirement during the backport process. During a backport request, even in the 'current' broken process, we need to make notes about the package and whether any changes are required for building in the backported release. Typically, these'd be determined by the person seeking the backport via PPA testing, etc. and then defined in the backport request.
We can possibly do a similar thing here - if no 'changes' are defined and the backport FTBFS in a PPA (such as a staging/proposed PPA like described above or like the Security team has), then reject the backport as-is because it fails to build. Any requests that require changes that aren't defined could be rejected because of FTBFS due to undefined changes necessary to get the package to build. Putting the requirement on defining changes to the individuals requesting/testing would offload that from the Backporters team.
This would also be part of the requests process - proof has to be made that the package builds and works in the target backported release with the Backports repo enabled (which as far as I can tell PPAs can be configured to do so).
------ 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 firstname.lastname@example.org 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.Perhaps reuse one of the existing lists, like devel-discuss? One thing to be careful of here though is setting expectations - we need to make sure that users don't think that backports will magically appear if they are requested.
This would work on devel-discuss, in my opinion, but as you said we need to be careful of setting expectations
This said, we can also define the process and make a note in nice bold text on the Wiki somewhere that "even if you request a backport, there is no guarantee that it will actually be backported - backports require someone to drive the individual backport itself and if nobody steps up to back the request and do the required legwork per this process to get the backport reviewed and ready for inclusion, the request will likely go unfulfilled."