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?
Pitti
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
