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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
