On Thu, Aug 29, 2019 at 11:14AM, Emilio Pozuelo Monfort wrote: > On 27/08/2019 21:50, Philipp Kern wrote: > > Do you have an opinion if this should actually be automated? I.e. > > automatically be fed into wb on a regular basis? I think the Release > > Team would also be the first team who would want to have a lever to stop > > that kind of automation from happening. Unfortunately I don't know how > > often those binNMUs would interfere with your day to day work. But I'd > > rather we run this centrally. > > Yes, we are ok with these binNMUs for haskell, ocaml, golang... to happen > automatically, as long as there's a mechanism to temporarily block them (e.g. > due to some transitions, or to the freeze).
For me, it would be best if this would not run automatically, to guard us against cases were a wrong version of a package is being uploaded to unstable (instead of experimental) and triggers binNMUs before we have a chance to revert our mistake. In addition, there may be cases where we only want to schedule part of the script's output. We are experiencing this now where ghc is (currently) unbuildable on mipsel/mips64el, and scheduling binNMUs for these architectures would be a waste of resources. > Why don't you let the interested teams run the scripts and generate the > required > binNMUs (like they do now), and then you pull that from a cronjob in wuiet and > schedule the binNMUs? You would just need to define the format and do some > sanity checks. I believe this would work for us, because we would be able to enable/disable binNMUs on demand (start/stop the script) and alter the output before submitting it. But then, whoever runs the script basically has access to the wanna-build infrastructure, and it seems to me that the wanna-build team want to avoid that. Best, -- Ilias
