On Tue, May 1, 2018 at 2:08 PM, Nick Kew <[email protected]> wrote: > >> That's not quite fair. >> >> For me, to be honest, I couldn't quite understand the question at >> all... I had a real hard time parsing it. It looked like, by voting +1, >> I would also be agreeing to other things (like disallowing >> any new features or enhancements to any release) which >> would be unacceptable. > > +1. I’d be uneasy about that clause without a much more in-depth > review of its context, which isn’t going to work as a mailinglist > discussion (too confusing; TL;DR). > > At the same time, I applaud what Bill is trying to do. We have a > problem, we discuss it, the discussion goes nowhere, Bill makes > a valiant effort to take it somewhere.
+1, I'd first like to thank Bill for trying to reach a consensus on our release numbering/policy. In the same time, I'm not sure three PMC members wanting a bug/security fixes only branch can prevent three others to backport improvement/feature there... So I'd like to ear Bill's further suggestions to "find mechanisms to accomplish this goal" which we could all agree/amend on, and move forward for the community benefits! Bill, withdrawing from the discussion shouldn't be the next step I think, please describe the whole picture as you see it (again? sorry if that happened already in the many/too much threads on the subject, at least I couldn't have that big picture yet). There is certainly a way to have both a conservative release (not exactly cast in stone either, to which extent?) and another or more ones with less API/ABI garantees (which grow faster and attract devs, maintained until?). It seems that the status quo is not what all of us/the community want, either. > > I promise to try and contribute > a positive suggestion! +1 Regards, Yann.
