Does the backporters team need help?

[Iain Lane]

On Tue, May 02, 2017 at 03:26:12PM +0200, Martin Pitt wrote:
> Hello all,
> 
> Clint Byrum [2017-04-26 11:42 -0700]:
> > Excerpts from Iain Lane's message of 2017-04-25 09:18:31 +0100:
> > > The process is set up in such a way that there is a specific list of
> > > things that the requests have to contain, a specific set of meanings for
> > > bug statuses and a very onerous amount of testing required for
> > > non-trivial backports. Any or all of these things can be wrong per the
> > > policy, and they all make it very hard for the backporters team to
> > > manage. A new member might manage to triage some percentage of the bugs,
> > > but I suspect that very quickly they would get burned out with the
> > > process like the rest of us.
> > > 
> > > I think it's proven to be a poor and unworkable process and it should be
> > > fixed to enable more developer autonomy. That said, I don't have a new
> > > proposal to make right now but I would be interested in trying to work
> > > one out.
> > 
> > Indeed, it feels a bit heavy weight. I wonder if we could just make it
> > a little easier to become a backporter if you're already a developer.
> 
> Agreed. This process is still from an age where we didn't have package sets
> with their more fine-grained upload privileges, CLI tools for queue
> review/management, etc. 
> 
> As a first step t it might help to make the process similar to SRUs: After
> filing the backport request bug, a developer could just go ahead and upload it
> with "backportpackage" or "dput" by themselves -- it seems much simpler to me
> as an archive admin/backports team member to review it from the +queue page and
> just click accept than having to build/upload the backport by myself?

That doesn't go far enough IMO, although I think it is essential to any
sustainable solution.

Actually uploading the backport is the easy part. The hard part is all
the verification that goes before it. The process requires explicit
testing of *all* reverse dependencies. That burden is on the reporter,
but it also falls on the ~ubuntu-backporters member to verify this and
push back if it's not been done.

So if we let anyone upload backports (actually the ACL for that is ~motu
so that's already more or less there) then we might shift the
unreasonable burden from one team to a larger team, but it will still be
there. And the smaller team will still have to police the unreasonable
process.

Again not a formal proposal, but I think that this extreme level of
paranoia should be removed from the process one way or another and be
replaced with some much simpler to comply with rules and appropriate
safety warnings. Debian manages to get by without being so prescriptive,
and we should be able to as well.

Cheers,

-- 
Iain Lane                                  [ iain at orangesquash.org.uk ]
Debian Developer                                   [ laney at debian.org ]
Ubuntu Developer                                   [ laney at ubuntu.com ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20170502/f03c4ab4/attachment.pgp>