Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]
On 16200 March 1977, Michael Lustfield wrote: I do recall that the FTP masters would've been generally open to have such an auto-approver (but maybe I'm wrong), but that no-one stepped up yet to code it up? A few of us came up with some proof of concept designs/models, but we ultimately dropped the effort when it became clear the team wasn't interested in such tools. We considered continuing with a tool that would work for individual users reviewing their own work, but there just wasn't enough interest for that either. I'd be happy to help resurrect (the personal-use version of) the project/effort if there's any chance I won't be working on it by myself... The place for that feature to end up in is inside dak, obviously. That feature should read its config (is it enabled? for the current package? with which config for it?) from the database (projectb). And then just hook itself into the part of the uploading that redirects packages to NEW. And then one could look if it gets implemented a bit more generic and not NEW specific, but able to do something like this for any policy queue. (As in, backports NEW, p-u, whatever). So, configurable per queue. For the actual feature and the affected packages. Any MR going in that direction will be great. -- bye, Joerg
Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]
On Wed, 14 Jul 2021 18:48:24 +0200 Philipp Kern wrote: > On 14.07.21 13:47, Michael Biebl wrote: > > Am 14.07.21 um 12:59 schrieb Simon McVittie: > I do recall that the FTP masters would've been generally open to have > such an auto-approver (but maybe I'm wrong), but that no-one stepped up > yet to code it up? A few of us came up with some proof of concept designs/models, but we ultimately dropped the effort when it became clear the team wasn't interested in such tools. We considered continuing with a tool that would work for individual users reviewing their own work, but there just wasn't enough interest for that either. I'd be happy to help resurrect (the personal-use version of) the project/effort if there's any chance I won't be working on it by myself...
Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]
On 14.07.21 13:47, Michael Biebl wrote: Am 14.07.21 um 12:59 schrieb Simon McVittie: Would it be feasible for dak to have a list of binary package name regexes mapped to a source package and a section/priority, and auto-accept packages from the given source package that match the regex, assigning the given section/priority, without manual action? That would let the ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/ in libs/optional, for example. It seems like this would also be good for src:linux, where ABI breaks are often tied to security fixes that should enter the archive ASAP. If something fully automated like this would be implemented, I would have much less concerns with this option. As it stands today, NEW processing is simply to unpredictable. It can range from taking a a few hours/days to several months. And yet it should not dictate technical solutions. We basically see the same thing with nvidia-graphics-drivers that break your running applications when the libraries are upgraded and you don't reboot. Arguably the proper solution is to version them with the full major/minor version. But I can see how that's a total hassle with NEW processing for both for the maintainer and to the FTP team. I do recall that the FTP masters would've been generally open to have such an auto-approver (but maybe I'm wrong), but that no-one stepped up yet to code it up? Kind regards Philipp Kern
Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]
Am 14.07.21 um 13:47 schrieb Michael Biebl: Am 14.07.21 um 12:59 schrieb Simon McVittie: Would it be feasible for dak to have a list of binary package name regexes mapped to a source package and a section/priority, and auto-accept packages from the given source package that match the regex, assigning the given section/priority, without manual action? That would let the ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/ in libs/optional, for example. It seems like this would also be good for src:linux, where ABI breaks are often tied to security fixes that should enter the archive ASAP. If something fully automated like this would be implemented, I would have much less concerns with this option. Fwiw, I like your proposal and would like to see it implemented regardless of the issue at hand as I think it could be generally useful. Thanks, Simon! OpenPGP_signature Description: OpenPGP digital signature
automatic NEW processing [was Re: Need help with Multi-Arch in systemd]
Am 14.07.21 um 12:59 schrieb Simon McVittie: Would it be feasible for dak to have a list of binary package name regexes mapped to a source package and a section/priority, and auto-accept packages from the given source package that match the regex, assigning the given section/priority, without manual action? That would let the ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/ in libs/optional, for example. It seems like this would also be good for src:linux, where ABI breaks are often tied to security fixes that should enter the archive ASAP. If something fully automated like this would be implemented, I would have much less concerns with this option. As it stands today, NEW processing is simply to unpredictable. It can range from taking a a few hours/days to several months. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
