Tuesday, 12 February 2019

Re: Backports and a Proposal for Changing the Process

My apologies for a slower reply, been messing with my mail gateways and had to deal with that first.

On 2/7/19 11:01 AM, Robie Basak wrote:
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.  
I am not in disagreement with 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 [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.  
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 ubuntu-backports@lists.ubuntu.com 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."