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.
signature.asc
Description: This is a digitally signed message part
