Re: Haskell binnmus is there a problem?
On 29/08/2019 11:32, Ilias Tsitsimpis wrote:
> 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.
Well, Philipp is a wb admin and is open to the idea. Besides, 'wb gb' is already
open to every DD. Opening 'wb nmu' a little bit (in cases where it makes sense
such as these, with proper auditing and logging) would be sensible if you ask me.
Emilio
Reply to: