Excerpts from Iain Lane's message of 2017-05-02 15:03:43 +0100:
> 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.
>
How about a few blanket exceptions that robots could handle:
1) If the package does not exist in the target release, and is a
no-change backport from a later stable release, auto-approve it.
2) If the package has no rdepends in the target release, and is from a
later stable release, auto-approve it.
3) If the package's rdepends all have DEP8 tests, automatically run
them with the uploaded binary, and if they pass, approve it.
(1) and (2) can be done with a cron job and the launchpad API/madison.
(3) would require some development I think, to hookup backports to DEP8
testing.
Just looking at xenial-backports, (1) has two candidates in the queue
right now: cockpit, and bubblewrap (Full disclosure: I need this last
one for my day-job).
(2) has a few that I can see as candidates from bindeps (there may be builddeps)
ardour
camo
codeblocks
dolphin-emu
gramps
julia
shibboleth-sp2
mame
nautilus-admin
sslh
So, assuming those are all no-change backports, adopting those two might
take the current queue from 44 to 32. I see a few in the 44 that are
outright nopes, like libgcrypt and poppler.
I'd be open to writing these cron jobs, though I don't know where they'd
run, they'd need LP access to auto-approve stuff.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
