Backports and a Proposal for Changing the Process

[Robie Basak]

Hi Thomas,

Thank you for driving this, and sorry for the slow reply.

I'm in general agreement with your proposal. In particular, given that
the existing backporters team members haven't been able to find the time
to review and/or adjust the process recently, I'm in favour of asking
them to hand the reins to others who can, and I consider you able.

I also think there's little to lose in relaxing the backports rules to
encourage more to land right now, even if that increases regression
risk, given that the alternative is that backporting activity grinds to
a halt and the pocket remains unused.

Finally, there's the obvious question of snaps. I think that snaps are
much easier to manage for very similar use cases here. For example I was
able to snap certbot relatively easily, but am still working (with many
others) on getting the certbot SRU landed, which from a technical work
perspective is essentially the same task as a backport. I would still
encourage those interested in backports to look into snaps first.

However, I see no reason that this should block a bunch of volunteers
who prefer instead to continue with the traditional backports process
from doing so. We rely upon and value those who volunteer their time,
and I don't think it's up to anyone else to dictate where they choose to
spend their efforts. An exception might be if there were some technical
collision that forces us to choose, but I see no such collision here. As
long as we don't draw others into the deb backports process who would
genuinely prefer the snap process.

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 [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.

>  
>  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.

> ------
> 
> 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 at 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.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20190207/28671aa9/attachment.sig>