On Wed, 4 Oct 2023, 20:07 Matthias Bläsing, <mblaes...@doppel-helix.eu.invalid> wrote:
> I was asked to reply here: > > I'm irritated, that votes are called for packages, that violate Apache > Release requirements (at least to my understanding). > > I will not vote on dlight.nativeexecution as I assume the reaction will > also be just a shrug. The question that remains: Why call a vote then? > So we can host the binaries on dist.a.o rather than the far worse shadow releasing via OSUOSL that was used for the last update. I'm sorry you're irritated by this, but understand it. I made a judgement call to keep the binary artefact contents the same for this first trial. This causes a minor violation of the release policy on convenience binaries, I realise, even though not really public facing. I wish I'd realised that earlier! It is still far less of one than putting them on OSUOSL in my opinion. It is at least a step in the right direction. The actual voting artefact (source) is compliant, if the contents are a little odd at present. Again, it was a judgement call to try this with the workflow without changing too much in the module itself. Both things need addressing in the NB21 cycle if this works for us. It's on my to-do list already leading on from this. If the vote doesn't pass then someone else will need to do the various PRs (I'm tied up most of next week), or we delay freeze, or we have another release without Apple Silicon support? I'm a little irritated with myself for not foreseeing this problem. Hindsight is great, sorry! Best wishes, Neil
