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-backpo...@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 stresso
