On Wed, 2021-03-17 at 19:51 +0100, zimoun wrote:
> It shows exactly my point.  The correct and polite way of doing the
> thing is first to examine the issue at hand (3.4.10 is old with
> security
> vulnerabilities), then propose a fix (e.g., the removal), wait
> feedback,
> and complete.

Actually we did not know pushing a security fix with 3.4.24 was not
fine, from quick auditing I have made 3.4.24 would still be under AGPL
so it would be fine to upgrade, turns out not since some files inside
are under SSPL but that was discovered way later, even when Efraim had
doubt and reverted my commit we had a debate and Efraim bought my
arguing even though I was wrong and they were right, if for every
security issue I have to ask feedback I may not ship them in a timely
manner, so that's also why they tend to be pushed faster than usual..
we may want to establish a clear process here. I usually create issues
for things I need help on, if I can do it myself and feel confident, I
just push, I can be wrong of course and always sorry for issues, I fix
them shortly in next commits if any.