Hi Zeev, Not trying to be a distraction(I shouldn't even have messaged), but I guess you might be waking everyone up to some facts these recent days(probably in the wrong way, and to some; positive).
Why did i write this? I've been following closely lately and have seen you(Zeev Suraski) question *RFC authority*(what it was meant for or not, even though your facts weren't written as facts anywhere). You've questioned the *mailing list* rules(be it binding or not), maybe it should be followed or disregarded and just follow my/your-style rules. You've questioned the *RFC votes*(majority can never be 2/3 but only 7/1),even thousands of majority votes can never push a deprecation through to the php-src because you didn't agree to that and possibly there's a veto somewhere which can be used because you are one of those listed in the PHP Group. Is this not mocking PHP internal developers to the outside world when you could just sit at home and chill or take a coffee when you can? Like Dan said, some old members are not following the mailing list rules(what you call moral etiquette), maybe since everything in the PHP internals has been going without a goal, why not just have the initial developer(Rasmus ledorf) or a group of people write out one(clear mission, goal statement, milestones, rules, etc) and stop the easy confusion going on in this mailing list? On Wed, Sep 18, 2019, 11:11 PM Zeev Suraski <z...@php.net> wrote: > On Wed, Sep 18, 2019 at 8:33 PM Dan Ackroyd <dan...@basereality.com> > wrote: > > > # Problem 3 - Newcomers to the mailing list aren't following our > > etiquette. > > # Problem 4 - Senior project members aren't following our email etiquette. > > > This too isn't directed so much at Dan, but rather the list at large. > > Some facts about the Mailing List Rules: > > Fact #1: The list rules were never a binding document. It wasn't voted on > or otherwise agreed upon as binding at any point at any point. In fact, I > can't even find any reference that it was even ever discussed (my email > archive dates back to 1999). It was written by Lukas Kahwe Smith, and with > the exception of some whitespace and typo fixes - it's literally in an > "initial commit .. feedback appreciated" stage ( > https://github.com/php/php-src/blame/master/docs/mailinglist-rules.md). > Fact #2: It contains three chapters. The first chapter - which includes > the goals of the document - i.e., what the other rules are aimed to > ultimately facilitate - is concluded with "Increase the general level of > good will on planet Earth". <opinion>This rule is clearly violated time and > again by several recent folks and proposals.</opinion> > Fact #3: Chapter 2 contains the rules, i.e., the supposedly binding rules > (see Fact #1). I think they're all healthy and non controversial, and we > should all strive to abide by them. <opinion>That said, interestingly, some > of the folks who most clearly violate the first item on this chapter appear > to eagerly want to enforce this document as binding.</opinion> > Fact #4: Chapter 3 contains "general hints", which are clearly non-binding > even if the document itself was (see Fact #1). Specifically, the first two > items in the 3rd chapter are purposely phrased as suggestions on what to do > as opposed to Thou Shalt or Thou Shalt Not, even if one ignores the > 'general hints' label that is applied to this entire section. These items > appear to be repurposed by some here as a way to silence opposition to > extremely controversial proposals. A "you should try to do X" request in a > "general hints" section in a document that was apparently never agreed upon > as binding will not do that, nor will anything else. > Bonus fact: Decision was only achievable through near-consensus back in > the day these rules were written; Substantial opposition wasn't facing the > risk of being ignored and overrun as it does today.. > > There's another fact about what RFCs can or cannot do, but I think I've > spent enough digital ink on that already. > > The recent discussions we've had on this list were not pleasant for anyone. > To say I took no pleasure at the discussions of the last few months would > be a top contender for the understatement of the century. However, from my > POV - I had no choice in the matter - and had to react to discussions that > were imposed on me. The alternative - which I view as betraying countless > users - isn't a real alternative from my point of view. I know for a fact > that many others had similar thoughts (yes, beyond just Chase and Stas) - > but were wary about voicing their opinions when they saw the 'summary > trials' I faced in certain forums, or just didn't have the energy to fight > what appeared to be a sisyphic task against an internals@ majority that > doesn't seem to care. > > There are very few folks on internals@ that are actively working to > protect > PHP's excellent BC track record, as well as keeping it from severing its > roots. It does mean that they are disproportionately represented in such > discussions. While I would absolutely love there to be others that will > join this effort that is as of late repeatedly imposed on us - we will > continue doing what we have to. > > Ultimately, the only way to avoid having these tiresome, waste of time > controversial discussions, is to stop bringing up controversial zero sum > game proposals. If you accidentally bring one up - backtrack, and figure > out a win/win solution or simply abandon it. If you insist on following > through with it - while spending plenty of Good Will credit and forcing > people to defend their positions - expect to have to endure a pretty tough > debate. No mailing list rules or RFCs will change that. > > Zeev > > P.S.: Intimidating folks by "noting their response time" - when their > response clearly doesn't violate anything about the rules - isn't only > gross, it's a downright regression to 1984. The antithesis for the stated > goals of the document, and knowing Lukas - probably the very exact opposite > to what he had in mind. Nobody should do that. >
