Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » RFC Abolish Narrow Margins »

RFC Abolish Narrow Margins

php.internals

Joe Watkins

7 years ago
Afternoon internals, Some time ago I brought up for discussion: https://wiki.php.net/rfc/abolish-narrow-margins I intend to bring this up for vote in the next few days. Cheers Joe

Zeev Suraski

7 years ago
>-----Original Message----- >From: Joe Watkins <krakjoe@gmail.com> >Sent: Thursday, January 31, 2019 2:59 PM >To: internals@lists.php.net >Subject: [PHP-DEV] RFC Abolish Narrow Margins > >Afternoon internals, > >Some time ago I brought up for discussion: >https://wiki.php.net/rfc/abolish-narrow-margins > >I intend to bring this up for vote in the next few days.
Joe, Given that time that passed since I brought up my wider-scoped RFC, and yet haven't pushed it through (some major things were happening on my end, as you may have heard...) - I can imagine you're not going to like what I'm going to say, but fundamentally - nothing changed. It still doesn't make sense, IMHO, to discuss the margin independently of other questions - even if you explicitly mention them as being outside of the scope of the RFC. Also, given the time that passed and the importance of this, it should require a brand new mandatory 2-week discussion period before we go for a vote - even if you insist on moving forward with this narrow-scoped RFC. At the same time, I'd like to finally solicit feedback explicitly on my wider-scoped RFC, as I guess we can't wait any longer. I'll send a separate email about that. Zeev

Joe Watkins

7 years ago
Afternoon Zeev, I imagine you will not like what I have to say either: In light of the recent actions you have taken and are taking to push incomplete software into php-src on narrow margins, prematurely, it makes perfect sense to discuss margins independently, and I intend to do so. Your opinion will be taken into consideration when you cast your vote. I do insist, and will not be waiting two weeks, unless you agree to delay the JIT RFC until this issue is resolved. Cheers Joe On Thu, 31 Jan 2019 at 14:07, Zeev Suraski <zeev@zend.com> wrote:

Zeev Suraski

7 years ago
Joe, First, you have to wait an absolute minimum of one week, and arguably two weeks, from the point in time you say you intend to move ahead with the RFC for a vote. That’s per the ratified Voting RFC, this really isn’t up for the individual RFC author to decide. It’s clear that an author can’t wake up a year after a certain discussion and move directly to a vote, even in the poorly written Voting RFC that’s currently in effect. Given the far reaching implications of this particular RFC, it’s pretty clear that this shouldn’t be one of the short, 1-week ones, but I guess this is open for interpretation (yet another illness of the current Voting RFC that must be resolved). Re: JIT - I don’t think we should halt the discussion on the RFC, but I do think it should require a 2/3 majority – IFF we define the voting rights and other topics. In other words – we can start discussing the merits and downsides of the RFC – but should probably wait with the vote itself until that’s cleared. For the record, I resent the language you used and the mal-intentions you attribute to me here. I’ll leave it at that. Zeev From: Joe Watkins <krakjoe@gmail.com> Sent: Thursday, January 31, 2019 3:26 PM To: Zeev Suraski <zeev@zend.com> Cc: internals@lists.php.net Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins Afternoon Zeev, I imagine you will not like what I have to say either: In light of the recent actions you have taken and are taking to push incomplete software into php-src on narrow margins, prematurely, it makes perfect sense to discuss margins independently, and I intend to do so. Your opinion will be taken into consideration when you cast your vote. I do insist, and will not be waiting two weeks, unless you agree to delay the JIT RFC until this issue is resolved. Cheers Joe On Thu, 31 Jan 2019 at 14:07, Zeev Suraski <zeev@zend.com<mailto:zeev@zend.com>> wrote:
>-----Original Message----- >From: Joe Watkins <krakjoe@gmail.com<mailto:krakjoe@gmail.com>> >Sent: Thursday, January 31, 2019 2:59 PM >To: internals@lists.php.net<mailto:internals@lists.php.net> >Subject: [PHP-DEV] RFC Abolish Narrow Margins > >Afternoon internals, > >Some time ago I brought up for discussion: >https://wiki.php.net/rfc/abolish-narrow-margins > >I intend to bring this up for vote in the next few days.
Joe, Given that time that passed since I brought up my wider-scoped RFC, and yet haven't pushed it through (some major things were happening on my end, as you may have heard...) - I can imagine you're not going to like what I'm going to say, but fundamentally - nothing changed. It still doesn't make sense, IMHO, to discuss the margin independently of other questions - even if you explicitly mention them as being outside of the scope of the RFC. Also, given the time that passed and the importance of this, it should require a brand new mandatory 2-week discussion period before we go for a vote - even if you insist on moving forward with this narrow-scoped RFC. At the same time, I'd like to finally solicit feedback explicitly on my wider-scoped RFC, as I guess we can't wait any longer. I'll send a separate email about that. Zeev

Joe Watkins

7 years ago
Afternoon Zeev, I'm going to use unambiguous and direct language to make sure my intentions and concerns are communicated clearly, you can either receive this as a personal attack, or as a contributor being direct, I would prefer the latter. Let us be clear about the things you are doing: You pushed FFI into php-src on a simple majority, it had one user, was incomplete (with leaks), and had zero justification for being included in php-src - it didn't require any internal API's and can function just fine as a PECL extension, still you pushed through with the RFC and it was accepted on a simple majority. You are now trying to push JIT into php-src on the same slim, clearly unacceptable majority, and even if you change the majority requirements, what's worse is you want to include it in a minor version. Once again, this is an incomplete feature, failing to support the architectures we support and declaring them unimportant. You are pushing PHP towards a future where there is effectively a single contributor, possibly two, able to make changes to Zend+Opcache; You are changing core parts of PHP too fast and making other contributors, including the maintainers of external tooling which the ecosystem requires to function, uncomfortable. I really don't think you have bad intentions, but think our processes are allowing us to make questionable decisions for the whole project, and this I intend to resolve, regardless of your next actions, before any more questionable decisions can be taken. Cheers Joe On Thu, 31 Jan 2019 at 14:38, Zeev Suraski <zeev@zend.com> wrote:

Zeev Suraski

7 years ago
On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins <krakjoe@gmail.com> wrote:
> Afternoon Zeev, > > I'm going to use unambiguous and direct language to make sure my intentions > and concerns are communicated clearly, you can either receive this as a > personal attack, or as a contributor being direct, I would prefer the > latter. >
I fail to see how in the way it was written it could not be taken as a personal attack, but since you wrote it, I'll happily take your interpretation of it. No hard feelings.
> You pushed FFI into php-src on a simple majority
I didn't push FFI. Yes, it was my idea to invest in it a year or two ago, but Dmitry took it from A to Z. Contrary to popular belief, we're not the same person, nor do we have a hive mind...
> was > incomplete (with leaks),
I would say that Dmitry has by far the best track record of fixing any outstanding issues - not only with his code, but with the code of mostly everyone else contributing to PHP, so if there's one contributor where this isn't something to worry about - that's him.
> and had zero justification for being included in > php-src - it didn't require any internal API's and can function just fine > as a PECL extension
Functionality isn't everything. Very few extensions have a technical requirement to be bundled - it's much more of a question of promotion.
> still you pushed through with the RFC and it was > accepted on a simple majority. >
I did not push this RFC in any way, nor did I even try to ask others to vote for it (which I would have if I was 'pushing' it). I actually agree with you that the fact it didn't clear a 2/3 vote, and with a hefty margin - is not very ideal. You are now trying to push JIT into php-src on the same slim, clearly
> unacceptable majority, and even if you change the majority requirements, > what's worse is you want to include it in a minor version. Once again, this > is an incomplete feature, failing to support the architectures we support > and declaring them unimportant.
I categorically disagree that it is an incomplete feature; I presume you're saying this because it currently supports Linux x86/x64? Does that make our mod_php feature incomplete because it doesn't support Windows? Is Swoole incomplete because it only supports Linux and Mac? It's not unusual for complicated pieces of software to first be available for specific subsets of platforms, and than gradually be ported to others. It may not be the intention, but it's difficult not to take calling it "incomplete" as something other than disparaging the mind-boggling levels of effort that went into it over the last 7 years. Seriously, it's akin to someone handing us a goose that lays golden eggs, for free, and us complaining that they require these special weeds to feed on. You are pushing PHP towards a future where
> there is effectively a single contributor, possibly two, able to make > changes to Zend+Opcache; You are changing core parts of PHP too fast and > making other contributors, including the maintainers of external tooling > which the ecosystem requires to function, uncomfortable. >
These are valid concerns, which is why they are fact covered in the RFC. Of course, it would be possible to make changes to the engine/OPcache without maintaining JIT - which would in turn break only JIT, in case we reach a situation where JIT has no maintainers, or they're unable to keep up with the changes. The architecture is purposely designed in a way that the engine remains independent of the JIT layer. I really don't think you have bad intentions, but think our processes are
> allowing us to make questionable decisions for the whole project, and this > I intend to resolve, regardless of your next actions, before any more > questionable decisions can be taken.
I think there were questionable decisions that happened long before FFI/JIT, and still, it didn't cross my mind to suddenly change the rules for them specifically. I'm fine with waiting with the JIT vote until we figure out voting. I don't think we're in any rush as far as the decision is concerned (and we can start discussing anyway). I'm not fine with rushing to hastily change the rules (while breaking the existing ones) to counter a specific RFC. Zeev

Joe Watkins

7 years ago
Afternoon Zeev,
> I'll happily take your interpretation of it. No hard feelings.
Thanks, you know I don't have another way of being :) When I refer to "you", I really mean you and Dmitry, while you don't have a hive mind, you do act as one, or for one another in a lot of cases. If I'm wrong about that, I apologise.
> I would say that Dmitry has by far the best track record of fixing any
outstanding issues I would agree, however it was Dmitry that wrote the RFC, and Dmitry that said it had leaks ... what am I supposed to think about that ? If someone does a patch for /Zend and it leaks or is suboptimal in any way, it does not land on Dmitry's say so, but it's okay for him to merge stuff with known defects ... I think the problem there is quite clear.
> Functionality isn't everything. Very few extensions have a technical
requirement to be bundled - it's much more of a question of promotion. So you want to say that for FFI to be used, it had to be included in php-src ? That's nonsense, the kind of people who are capable of using FFI are also capable of installing an extension. From my perspective it had no justification for being merged at all, but there were very good reasons to keep it out of php-src not least the slim majority on which it was merged.
> I actually agree with you that the fact it didn't clear a 2/3 vote, and
with a hefty margin - is not very ideal. So it sounds like we agree here, it was pushed into php-src on an unacceptable margin.
> I categorically disagree that it is an incomplete feature; I presume
you're saying this because it currently supports Linux x86/x64? This sounds disingenuous to me, you are trying to make it sound ready before it actually is.
> It's not unusual for complicated pieces of software to first be
available for specific subsets of platforms, and than gradually be ported to others That's true, but Windows is a core platform for PHP, if you haven't got Windows, you got nothing. I wouldn't make such a fuss about windows or fancy architectures, if I thought there was anyone around who could actually implement them, as far as I know there isn't and if they are unimportant to dmitry and yourself, then it won't get done.
> I think there were questionable decisions that happened long before
FFI/JIT, and still, it didn't cross my mind to suddenly change the rules for them specifically. Check the date on the rfc, nothing is happening suddenly.
> I'm not fine with rushing to hastily change the rules (while breaking
the existing ones) to counter a specific RFC. As I have already explained, I'm prompted to act because of a pattern of behaviour and decisions that I find questionable, and so do others ... and by your own admission, so do you ... I should make clear that I think FFI is really cool although I haven't found time to play with it yet, and clearly I want us to have a JIT, and marvel at the achievement. I can't wait to start reading it (again) and trying to understand. This is not about one or two RFCs, but making simple changes to give us more confidence in the decisions we are all making, and it certainly isn't an attack on you or Dmitry, nothing of the sort ... I think we don't really have anything to argue about, and to reiterate, I will be taking this RFC to vote. Cheers Joe On Thu, 31 Jan 2019 at 16:13, Zeev Suraski <zeev@php.net> wrote:

Dmitry Stogov

7 years ago
Hi Joe, On 1/31/19 6:56 PM, Joe Watkins wrote:
> Afternoon Zeev, > >> I'll happily take your interpretation of it. No hard feelings. > > Thanks, you know I don't have another way of being :) > > When I refer to "you", I really mean you and Dmitry, while you don't have a > hive mind, you do act as one, or for one another in a lot of cases. If I'm > wrong about that, I apologise. > >> I would say that Dmitry has by far the best track record of fixing any > outstanding issues > > I would agree, however it was Dmitry that wrote the RFC, and Dmitry that > said it had leaks ... what am I supposed to think about that ? If someone > does a patch for /Zend and it leaks or is suboptimal in any way, it does > not land on Dmitry's say so, but it's okay for him to merge stuff with > known defects ... I think the problem there is quite clear.
The fact that FFI may leak, is because it uses "unmanaged memory" (like in real C). PHP reference counting and GC just can't handle all the cases. It's impossible to automatically know what to do with C pointer, when we get it from function or another structure. In this case programmer have to care about freeing the pointer themselves (like in C). This is all about the FFI leaks. Thanks. Dmitry.

Zeev Suraski

7 years ago
On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov <dmitry@zend.com> wrote:
> The fact that FFI may leak, is because it uses "unmanaged memory" (like > in real C). PHP reference counting and GC just can't handle all the > cases. It's impossible to automatically know what to do with C pointer, > when we get it from function or another structure. In this case > programmer have to care about freeing the pointer themselves (like in C). > > This obviously doesn't count as 'leaks'. If it did, we could say that the
Zend Extension API leaks, as it's completely up to the developer to handle memory management. Joe - if that's your concern, I think it's fair to say it's invalid and you have nothing to worry about. Zeev

Joe Watkins

7 years ago
Hi Zeev, Dmitry, It is not my only concern, I'm grateful for the clarification whatever. These are your actual words from the RFC:
> This works, but this functionality is not supported on all libffi
platforms, it is not efficient and leaks resources by the end of request. It's recommended to minimize the usage of PHP callbacks. To me, a foreign function interface where one side of the interface sounds broken and inefficient, according to the author, is scary. I've never worked with libffi, so don't know if that's normal ... but I think you can understand my thoughts here. Aside from whatever technical issues I may have misinterpreted or misidentified, these are not my main objections to it being merged. Cheers Joe On Thu, 31 Jan 2019 at 17:20, Zeev Suraski <zeev@php.net> wrote:

Zeev Suraski

7 years ago
On Thu, Jan 31, 2019 at 5:56 PM Joe Watkins <krakjoe@gmail.com> wrote:
> When I refer to "you", I really mean you and Dmitry, while you don't have > a hive mind, you do act as one, or for one another in a lot of cases. If > I'm wrong about that, I apologise. >
You are wrong, apology accepted.
> > I would say that Dmitry has by far the best track record of fixing any > outstanding issues > > I would agree, however it was Dmitry that wrote the RFC, and Dmitry that > said it had leaks ... what am I supposed to think about that ? If someone > does a patch for /Zend and it leaks or is suboptimal in any way, it does > not land on Dmitry's say so, but it's okay for him to merge stuff with > known defects ... I think the problem there is quite clear. >
See separate reply from both Dmitry and me. Sounds like a large part of what brought you to vote against FFI was misunderstanding of the situation. Which I guess can still be blamed on the RFC author, but at least, this concern should be alleviated now.
> Functionality isn't everything. Very few extensions have a technical > requirement to be bundled - it's much more of a question of promotion. > > So you want to say that for FFI to be used, it had to be included in > php-src ? That's nonsense, the kind of people who are capable of using FFI > are also capable of installing an extension. >
Joe, please, this language is counter-productive. Even more so when you're first putting words in my mouth, but also without it. Can we discuss things politely without telling the other party that they're being nonsensical? I did not say that that "it had to be included in php-src in order to be used". Neither does ext/mysqli or any other extension for that matter. I *did* and *am* saying that it will *promote* its usage. As is the case with most promotions - the lack of promotion does not necessarily mean complete and utter failure, but the presence of promotion may yield better results than without it. I very much stand by my statement that bundling extensions in PHP is predominantly about promotion and ease of use, than it is about technical requirements.
> From my perspective it had no justification for being merged at all, but > there were very good reasons to keep it out of php-src not least the slim > majority on which it was merged. >
It wasn't such a slim majority, it was 62% IIRC, which is a lot closer to the 2/3 needed than the 1/2 that was defined for it. That said, I think it's sad it didn't clear the vote with a much higher margin - well above 2/3 - and I'm making a cautious bet than misunderstandings around potential leaks may have had something to do with it, and had it been clear that these potential "leaks" are in fact an inherent element of FFI, and not a limitation of the implementation - it would likely have gotten a lot fewer negative votes.
> I actually agree with you that the fact it didn't clear a 2/3 vote, and > with a hefty margin - is not very ideal. > > So it sounds like we agree here, it was pushed into php-src on an > unacceptable margin. >
"Unacceptable" is your statement, not mine. We're not in a black and white world - it's grey. I think that with the current rules, it's 100.0% acceptable. Would I prefer that it cleared the vote with a much higher, 80-90% margin? Yes. For JIT, which is a much bigger deal in every respect compared to FFI, I think it makes sense to take a pause and make sure we have our rules in order before we move forward.
> I categorically disagree that it is an incomplete feature; I presume > you're saying this because it currently supports Linux x86/x64? > > This sounds disingenuous to me, you are trying to make it sound ready > before it actually is. >
I can't control what it sounds like to you. I can only control what I say, and I know that I'm saying it with 100% sincerity based on my view of the world and the importance of the different deployment platforms in the PHP space.
> It's not unusual for complicated pieces of software to first be > available for specific subsets of platforms, and than gradually be ported > to others > > That's true, but Windows is a core platform for PHP, if you haven't got > Windows, you got nothing. >
As the person who made PHP a first class citizen under Windows back in the day (based on tons of prior work by Shane Caraveo), I wholeheartedly disagree. Windows support is not *nearly* as important as Linux support, especially not when we deal with production systems - which is what JIT is geared at. Windows it a tiny tiny fraction compared to Linux as far as deployments are concerned. The situation is different when we deal with development - but that's mostly orthogonal to JIT (again, a production feature) - plus recent trends make it even less of an issue, as even a developer running Windows is today more likely to be running PHP in a Linux container/VM, than natively on Windows. I wouldn't make such a fuss about windows or fancy architectures, if I
> thought there was anyone around who could actually implement them, as far > as I know there isn't and if they are unimportant to dmitry and yourself, > then it won't get done. >
Saying it's "not a priority" is not quite the same as saying it's not important. It's actually not the same at all. Let me bounce back what this whole thread sounds like - not to me, but how I imagine it would sound to Dmitry: "So you worked your behind off for 7 years to get this going. I think we shouldn't even be discussing it, because it's incomplete - because some architecture that a tiny fraction of PHP's users are using for production isn't supported. Get back to us when it's ready. Oh, heads up - I'd also be against admitting this feature to the codebase altogether and will fight against it, as I think it'll be impossible to maintain. But I won't even discuss that with you right now, please spend another 6 months porting it to Windows because I shoot it down."
> > > I think there were questionable decisions that happened long before > FFI/JIT, and still, it didn't cross my mind to suddenly change the rules > for them specifically. > > Check the date on the rfc, nothing is happening suddenly. >
To use your own words, this sounds disingenuous to me. You know exactly what happened, and why you *suddenly* popped up the RFC from the drawer for immediate voting. The Voting RFC clearly states that the date on the RFC itself is meaningless, and the count begins from the point in time you send an email to the mailing list with your intention to bring that RFC for a vote. That day is today.
> I'm not fine with rushing to hastily change the rules (while breaking > the existing ones) to counter a specific RFC. > > As I have already explained, I'm prompted to act because of a pattern of > behaviour and decisions that I find questionable, and so do others ... and > by your own admission, so do you ... > > I should make clear that I think FFI is really cool although I haven't > found time to play with it yet, and clearly I want us to have a JIT, and > marvel at the achievement. I can't wait to start reading it (again) and > trying to understand. This is not about one or two RFCs, but making simple > changes to give us more confidence in the decisions we are all making, and > it certainly isn't an attack on you or Dmitry, nothing of the sort ... > > I think we don't really have anything to argue about, and to reiterate, I > will be taking this RFC to vote. >
That's regrettable IMHO, regardless of when that happens. However, if it happens before we clear the two week discussion period - I will be ignoring the results of this illegitimate vote, and would be encouraging others to do the same (both the voting process, and whatever the results would be). If you insist on putting it to a vote that's obviously entirely within your right - but please play by the same rules that apply to everyone else and provide us with the required discussion period. Zeev

Nikita Popov

7 years ago
On Thu, Jan 31, 2019 at 2:07 PM Zeev Suraski <zeev@zend.com> wrote:
> >-----Original Message----- > >From: Joe Watkins <krakjoe@gmail.com> > >Sent: Thursday, January 31, 2019 2:59 PM > >To: internals@lists.php.net > >Subject: [PHP-DEV] RFC Abolish Narrow Margins > > > >Afternoon internals, > > > >Some time ago I brought up for discussion: > >https://wiki.php.net/rfc/abolish-narrow-margins > > > >I intend to bring this up for vote in the next few days. > > Joe, > > Given that time that passed since I brought up my wider-scoped RFC, and > yet haven't pushed it through (some major things were happening on my end, > as you may have heard...) - I can imagine you're not going to like what I'm > going to say, but fundamentally - nothing changed. It still doesn't make > sense, IMHO, to discuss the margin independently of other questions - even > if you explicitly mention them as being outside of the scope of the RFC. > > Also, given the time that passed and the importance of this, it should > require a brand new mandatory 2-week discussion period before we go for a > vote - even if you insist on moving forward with this narrow-scoped RFC. > > At the same time, I'd like to finally solicit feedback explicitly on my > wider-scoped RFC, as I guess we can't wait any longer. I'll send a > separate email about that. > > Zeev >
I agree with Joe here that we should handle the question of voting margins separately. Your RFC is a much more comprehensive reform, which contains a number of points that look highly controversial to me (such as the eligible voter changes). It may take a long time until we reach a satisfactory consensus there. On the other hand, this RFC is very simple and at least to me a complete no-brainer. I already use 2/3 majority for all my votes, because I very strongly believe that changes to PHP need to be held to a much higher standard than a simple majority. It is outright shameful that functionality can be added to PHP if 21 vote in favor and 20 against. That's not a consensus, that's a complete disagreement. It's not necessary to decide all questions regarding the RFC process at once. Voting threshold is a very self-contained issue and we can decide it separately from other controversial changes. Regards, Nikita

Zeev Suraski

7 years ago
On Thu, Jan 31, 2019 at 4:55 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> I agree with Joe here that we should handle the question of voting margins > separately. Your RFC is a much more comprehensive reform, which contains a > number of points that look highly controversial to me (such as the eligible > voter changes). It may take a long time until we reach a satisfactory > consensus there. > > On the other hand, this RFC is very simple and at least to me a complete > no-brainer. I already use 2/3 majority for all my votes, because I very > strongly believe that changes to PHP need to be held to a much higher > standard than a simple majority. It is outright shameful that functionality > can be added to PHP if 21 vote in favor and 20 against. That's not a > consensus, that's a complete disagreement. > > It's not necessary to decide all questions regarding the RFC process at > once. Voting threshold is a very self-contained issue and we can decide it > separately from other controversial changes.
Well, I think there are several issues here. One - while the passing threshold is probably one of the most painful issues with the current Voting RFC, it's hardly the only one. Given it's taken us many years to start tackling this, I think it's safe to say that as a rule, we lack the motivation to tackle these issues. I think it's pretty clear that if we solve the threshold issue independently, it would likely be years before we tackle the other issues, if ever. Secondly - the threshold and voting eligibility are not, in any way, independent. They're two fundamental aspects of the same topic - how votes take place. A 2/3 majority out of a subset of ~200-300 people is very different from a 2/3 majority out of a potential group of several thousand people Thirdly - implementation issues - that the original Voting RFC did NOT intend to cover, later became covered by it by virtue of assumption. I think that implementation issues (implementing the same functionality that we have right now in a better way) should not be subject to a vote, and moving the threshold to 2/3 makes the current situation even worse than it currently is, and should be for the most part up to the maintainers of the code. So no, I don't think we can simply 'abolish narrow margins' without thinking about the implications as well as tackling the other shortcomings of the 2011 Voting RFC. With due respect, it reminds me of the hasty approach we took back then, and that wasn't good. Unless I'm missing something, we're currently in absolutely no hurry - we just released 7.3, we can spend as much time as needed (to a reason) on hashing out updated voting rules. I'm speaking on behalf of myself, and maybe Dmitry thinks differently - but I'm certainly fine waiting with that RFC for several weeks or even a couple of months if needed. Zeev

Nikita Popov

7 years ago
On Thu, Jan 31, 2019 at 4:27 PM Zeev Suraski <zeev@php.net> wrote:
> > > On Thu, Jan 31, 2019 at 4:55 PM Nikita Popov <nikita.ppv@gmail.com> wrote: > >> I agree with Joe here that we should handle the question of voting margins >> separately. Your RFC is a much more comprehensive reform, which contains a >> number of points that look highly controversial to me (such as the >> eligible >> voter changes). It may take a long time until we reach a satisfactory >> consensus there. >> >> On the other hand, this RFC is very simple and at least to me a complete >> no-brainer. I already use 2/3 majority for all my votes, because I very >> strongly believe that changes to PHP need to be held to a much higher >> standard than a simple majority. It is outright shameful that >> functionality >> can be added to PHP if 21 vote in favor and 20 against. That's not a >> consensus, that's a complete disagreement. >> >> It's not necessary to decide all questions regarding the RFC process at >> once. Voting threshold is a very self-contained issue and we can decide it >> separately from other controversial changes. > > > Well, I think there are several issues here. > > One - while the passing threshold is probably one of the most painful > issues with the current Voting RFC, it's hardly the only one. Given it's > taken us many years to start tackling this, I think it's safe to say that > as a rule, we lack the motivation to tackle these issues. I think it's > pretty clear that if we solve the threshold issue independently, it would > likely be years before we tackle the other issues, if ever. > > Secondly - the threshold and voting eligibility are not, in any way, > independent. They're two fundamental aspects of the same topic - how votes > take place. A 2/3 majority out of a subset of ~200-300 people is very > different from a 2/3 majority out of a potential group of several thousand > people > > Thirdly - implementation issues - that the original Voting RFC did NOT > intend to cover, later became covered by it by virtue of assumption. I > think that implementation issues (implementing the same functionality that > we have right now in a better way) should not be subject to a vote, and > moving the threshold to 2/3 makes the current situation even worse than it > currently is, and should be for the most part up to the maintainers of the > code. > > So no, I don't think we can simply 'abolish narrow margins' without > thinking about the implications as well as tackling the other shortcomings > of the 2011 Voting RFC. With due respect, it reminds me of the hasty > approach we took back then, and that wasn't good. > > Unless I'm missing something, we're currently in absolutely no hurry - we > just released 7.3, we can spend as much time as needed (to a reason) on > hashing out updated voting rules. I'm speaking on behalf of myself, and > maybe Dmitry thinks differently - but I'm certainly fine waiting with that > RFC for several weeks or even a couple of months if needed. > > Zeev >
Let me reply to the last point first, because I think that's really the crux here: The issue is not that this RFC is very urgent per se, it's that it has already been delayed numerous times and it is imperative that we prevent that from happening again. Since this issue was first raised, a number of RFCs have passed with narrow voting margins. Every time that happens, I think "damn, why didn't we go through with the voting threshold RFC?" This RFC has been delayed for various reasons in the past -- those reasons sounded good at the time, but the end effect is still the same: RFCs being accepted with unreasonable margins. If we delay this again and it turns out that your competing RFC stays in limbo for the next two years, or is simply not accepted due to changes unrelated to voting margins, I would consider that to be quite unfortunate. If you have concerns with the details of the rules outlined in this RFC, I'm sure that Joe is open to discussing them. But let's please make sure that this particular question is resolved in a timely manner, which I think requires it to be tackled separately from other issues. Regarding your point about implementation issues: I'm not really sure I understand it. Generally implementation issues are decided by a small group of people (usually Dmitry, Bob and myself), often without even going through the internals list. Of course very large changes (like say phpng) should go through the RFC process simply because they affect many more people (in particular also extension authors). Apart from that, I'm not sure which other "implementation" RFCs you have in mind here. Regards, Nikita PS: I think this thread went thoroughly off track and now mostly discusses the FFI extension rather than this RFC ... Maybe that should be moved elsewhere?

Zeev Suraski

7 years ago
On Thu, Jan 31, 2019 at 7:00 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> Let me reply to the last point first, because I think that's really the > crux here: The issue is not that this RFC is very urgent per se, it's that > it has already been delayed numerous times and it is imperative that we > prevent that from happening again. Since this issue was first raised, a > number of RFCs have passed with narrow voting margins. Every time that > happens, I think "damn, why didn't we go through with the voting threshold > RFC?" > > This RFC has been delayed for various reasons in the past -- those reasons > sounded good at the time, but the end effect is still the same: RFCs being > accepted with unreasonable margins. If we delay this again and it turns out > that your competing RFC stays in limbo for the next two years, or is simply > not accepted due to changes unrelated to voting margins, I would consider > that to be quite unfortunate. >
I've had similar issues with other aspects of the shortcoming of the 2011 Voting RFC. The 50%+1 vs 2/3 is really just one issue - it's an important one, but just one - and it doesn't live in vacuum. It's interrelated to other issues.
> If you have concerns with the details of the rules outlined in this RFC, > I'm sure that Joe is open to discussing them. But let's please make sure > that this particular question is resolved in a timely manner, which I think > requires it to be tackled separately from other issues. >
To me, changing the margins is like placing a band-aid on a gunshot wound. Or perhaps to be more fair, it's to start surgery on wound, but then stopping a 3rd way through or so. Unless the RFC is extended to cover all the key shortcomings of the 2011 Voting RFC, then it's a superficial fix that I can't be in favor of. Rushing it through bears the hallmarks of the issues that plagued the 2011 Voting RFC - putting something together quickly, not trying to think through all of the different scenarios and consequently not providing a comprehensive solution. Is the 2011 Voting RFC + permanent 2/3 margins still deeply flawed? I'd say absolutely yes. Then let's think on how we fix it holistically. If your concern is that RFCs would pass under this low margin as we debate - why not call for a 30 day pause on RFC votes altogether (extensible by another 30 days assuming there's still a healthy discussion), not just for JIT? I'm all for it. We have the time and apparently now also the inclination, let's finally settle this thing and make it right. Zeev

Stas Malyshev

7 years ago
Hi!
> Let me reply to the last point first, because I think that's really the > crux here: The issue is not that this RFC is very urgent per se, it's that > it has already been delayed numerous times and it is imperative that we > prevent that from happening again. Since this issue was first raised, a
That's understandable. But I think if we have an ongoing discussion now, waiting until this discussion comes to some conclusion or at least giving it some reasonable time to do so is a good thing. Note the "reasonable" part - it doesn't mean it should wait another 2 years. But if 2+ year old RFC is revived I think it's reasonable to wait a week or two with vote. Original margins were meant for situation where somebody puts up RFC and immediately proceeds to vote, not for situation where RFC lies dormant for 2 years, then revived and immediately proceeds to vote without most people even remembering what happened 2 years ago. I think in this case it's reasonable to wait a little bit - and I don't see a reason why not.
-- Stas Malyshev smalyshev@gmail.com

Joe Watkins

7 years ago
Morning Stas, and all, This discussion was ... a mess, partly my fault, I suppose. I said I was going to bring it up for voting quickly on the say so of Nikita, and because it feels urgent to us, you can guess our reasons for that. I'm not going to argue back and forth for the next week about the reasons we think this is important. In a week, let's say next Friday, to be totally fair, this RFC will go to vote. Cheers Joe On Fri, 1 Feb 2019 at 06:16, Stanislav Malyshev <smalyshev@gmail.com> wrote:

Nikita Popov

7 years ago
On Fri, Feb 1, 2019 at 6:16 AM Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > > Let me reply to the last point first, because I think that's really the > > crux here: The issue is not that this RFC is very urgent per se, it's > that > > it has already been delayed numerous times and it is imperative that we > > prevent that from happening again. Since this issue was first raised, a > > That's understandable. But I think if we have an ongoing discussion now, > waiting until this discussion comes to some conclusion or at least > giving it some reasonable time to do so is a good thing. Note the > "reasonable" part - it doesn't mean it should wait another 2 years. But > if 2+ year old RFC is revived I think it's reasonable to wait a week or > two with vote. Original margins were meant for situation where somebody > puts up RFC and immediately proceeds to vote, not for situation where > RFC lies dormant for 2 years, then revived and immediately proceeds to > vote without most people even remembering what happened 2 years ago. I > think in this case it's reasonable to wait a little bit - and I don't > see a reason why not. >
That's reasonable. What is important to me is that: a) We don't vote RFCs with low margins in the meantime. As a show of good faith, it would be nice to adjust the vote in the JIT RFC to require a 2/3 majority. b) The voting margin question is resolved separately from other concerns. I very specifically do not want this bundled with anything else. I don't want the voting margin adjustment to fail because of other changes bundled in the same RFC. Conversely, I do not want other changes in the same RFC to pass simply because it's the only way to get the voting margin changes. Nikita

Zeev Suraski

7 years ago
On Fri, Feb 1, 2019 at 1:38 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Fri, Feb 1, 2019 at 6:16 AM Stanislav Malyshev <smalyshev@gmail.com> > wrote: > >> Hi! >> >> > Let me reply to the last point first, because I think that's really the >> > crux here: The issue is not that this RFC is very urgent per se, it's >> that >> > it has already been delayed numerous times and it is imperative that we >> > prevent that from happening again. Since this issue was first raised, a >> >> That's understandable. But I think if we have an ongoing discussion now, >> waiting until this discussion comes to some conclusion or at least >> giving it some reasonable time to do so is a good thing. Note the >> "reasonable" part - it doesn't mean it should wait another 2 years. But >> if 2+ year old RFC is revived I think it's reasonable to wait a week or >> two with vote. Original margins were meant for situation where somebody >> puts up RFC and immediately proceeds to vote, not for situation where >> RFC lies dormant for 2 years, then revived and immediately proceeds to >> vote without most people even remembering what happened 2 years ago. I >> think in this case it's reasonable to wait a little bit - and I don't >> see a reason why not. >> > > That's reasonable. What is important to me is that: > > a) We don't vote RFCs with low margins in the meantime. As a show of good > faith, it would be nice to adjust the vote in the JIT RFC to require a 2/3 > majority. > > b) The voting margin question is resolved separately from other concerns. > I very specifically do not want this bundled with anything else. I don't > want the voting margin adjustment to fail because of other changes bundled > in the same RFC. Conversely, I do not want other changes in the same RFC to > pass simply because it's the only way to get the voting margin changes. >
I would like no RFCs to be voted on before we sort out the voting base as well. The more elaborate process can wait as it's probably not very relevant to the few RFCs that are in motion. But both the voting base and voting margins are very relevant. We will not be moving the JIT RFC into a vote before that happens. Zeev

Andrey Andreev

7 years ago
Hi, On Thu, Jan 31, 2019 at 5:28 PM Zeev Suraski <zeev@php.net> wrote:
> > Secondly - the threshold and voting eligibility are not, in any way, > independent. They're two fundamental aspects of the same topic - how votes > take place. A 2/3 majority out of a subset of ~200-300 people is very > different from a 2/3 majority out of a potential group of several thousand > people >
Does that really matter though? Your own proposal includes the 2/3 rule and I don't think you're saying 50%+1 is OK now, so what difference does it make? I don't see a reason why this RFC, which looks almost like just a formality, should be bundled with something way bigger and controversial. Cheers, Andrey.

Nikita Popov

7 years ago
On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins <krakjoe@gmail.com> wrote:
> Afternoon internals, > > Some time ago I brought up for discussion: > https://wiki.php.net/rfc/abolish-narrow-margins > > I intend to bring this up for vote in the next few days. > > Cheers > Joe >
After one day of heated discussion this thread has died down again. I'd like to make sure that there are no further concerns here before this goes to vote. Most of the discussion here has been around the question of whether or not this should be part of Zeev's RFC (and it doesn't look like we're going to agree on that one), but there has been little further discussion of the proposal itself. I guess that means it's fairly uncontroversial. As far as I can see the only difference between this proposal and Zeev's (as far as voting margins are concerned), is that this RFC requires a 2/3 majority, while Zeev's proposal excludes "PHP Packaging Decisions" and only requires a simple majority for them. There has been some brief discussion about this, with the following mail from Stas:
> 1. Do we really need different classification of changes? I think having > one single vote procedure would have larger benefit, and RFC that fails > 2/3 requirement would be suspect anyway. RFCs can have parts - "whether > we do it" and "how exactly we do it" - the former would be 2/3 > requirement, the latter can be simple plurality even - e.g. if we decide > to have an extension for libfoobar, that should have 2/3 vote, but then > decision between whether to name it foobar or barfoo can be decided by > majority or plurality.
And Zeev's response:
> I think we do. There are decisions where a 2/3 majority requirement makes > no sense, as the vote itself is about a choice between two options that
are
> on the table, as opposed to deciding whether to do something or not. > There aren't many such cases, but when they do occur - they tend to be > important. > > The most obvious case I have in mind is that of the choice between PHP 6 > and 7. It doesn't expose us to any future commitments, doesn't change the > language - it's arguably almost a marketing decision. Similarly, if we > decide to change our release schedule, I don't see why that should require > a 2/3 majority. The 'bias for the status quo', which is the main reason
we
> have the super majority requirement to begin with, doesn't really play a > role here - as it bears no long term commitment.
I'll add my own response here. I agree with Stas that it is preferable to have a single voting procedure and don't think that "packaging decisions" should be special cased. This is not just to in the interest of having simple rules, but also because I disagree with the premise that packaging decisions are somehow less important than changes to PHP or do not have future commitments. For example, extending support for a release by multiple years (a question that will probably come up for PHP 7.4), is a quite serious commitment of resources that should not be decided on a narrow margin. More importantly, while our past RFCs in the area of "packaging" have not been particularly major, that's isn't a property inherent to the category. For example, a proposal to introduce regular LTS releases, or to make other major changes to our release scheduling, should certainly be subject to a 2/3 majority. In each category (whether it's changes to PHP or the release process) there will always be more and less significant RFCs, and it's hard to draw a good line between them (we failed spectacularly trying to due that with "language changes"). I think it is better to err on the side of being conservative and require a 2/3 majority for everything, especially as it also obviates any arguments as to what requires or doesn't require a certain majority. Nikita

Zeev Suraski

7 years ago
On Wed, Feb 6, 2019 at 10:50 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
> More importantly, while our past RFCs in the area of "packaging" have not > been particularly major, that's isn't a property inherent to the category. > For example, a proposal to introduce regular LTS releases, or to make other > major changes to our release scheduling, should certainly be subject to a > 2/3 majority. In each category (whether it's changes to PHP or the release > process) there will always be more and less significant RFCs, and it's hard > to draw a good line between them (we failed spectacularly trying to due > that with "language changes"). I think it is better to err on the side of > being conservative and require a 2/3 majority for everything, especially as > it also obviates any arguments as to what requires or doesn't require a > certain majority.
I'll reiterate my main two issues with this RFC: - I do think that we need 50%+1 votes for certain decisions. Naming the next version of PHP, or even deciding to release it outside of the yearly cycle should not require a 2/3 vote. It's not so much erring on the side of being conservative - it's enforcing a bias for status-quo that simply doesn't exist in these issues. Is it the end of the world that we won't have it? No, but it's better that we would. - More importantly, the voting base issue must be solved before we change the voting rules. I find it extremely problematic process-wise that we'll change the rules using a voting base that was never defined to be valid in the first place. You mentioned that you don't see why the two issues are interlinked - and you may be right, it's more that one is dependent on the other. Voting eligibility is the first question we should answer, and it should only be followed by the voting rules themselves. In addition, rushing this RFC for a vote while the discussion of the more comprehensive approach is in motion is quite questionable in my opinion. Zeev

Niklas Keller

7 years ago
> I'll reiterate my main two issues with this RFC: > - I do think that we need 50%+1 votes for certain decisions. Naming the > next version of PHP, or even deciding to release it outside of the yearly > cycle should not require a 2/3 vote. It's not so much erring on the side > of being conservative - it's enforcing a bias for status-quo that simply > doesn't exist in these issues. Is it the end of the world that we won't > have it? No, but it's better that we would. > - More importantly, the voting base issue must be solved before we change > the voting rules. I find it extremely problematic process-wise that we'll > change the rules using a voting base that was never defined to be valid in > the first place.
It's the only definition we currently have. We have to rely on the same voting base to change the voting base. I don't see how voting on all other RFCs is fine, but voting on this one isn't.
> You mentioned that you don't see why the two issues are > interlinked - and you may be right, it's more that one is dependent on the > other. Voting eligibility is the first question we should answer, and it > should only be followed by the voting rules themselves.
We currently have an answer to voting eligibility. It's one you may not like, but changing that is completely independent of changing voting margins. Regards, Niklas

Zeev Suraski

7 years ago
On Wed, Feb 6, 2019 at 9:06 PM Niklas Keller <me@kelunik.com> wrote:
> > I'll reiterate my main two issues with this RFC: > > - I do think that we need 50%+1 votes for certain decisions. Naming the > > next version of PHP, or even deciding to release it outside of the yearly > > cycle should not require a 2/3 vote. It's not so much erring on the side > > of being conservative - it's enforcing a bias for status-quo that simply > > doesn't exist in these issues. Is it the end of the world that we won't > > have it? No, but it's better that we would. > > - More importantly, the voting base issue must be solved before we change > > the voting rules. I find it extremely problematic process-wise that > we'll > > change the rules using a voting base that was never defined to be valid > in > > the first place. > > It's the only definition we currently have.
That's not exactly true. We have the definition that was actually agreed upon in the original Voting RFC, and while it's hardly great - it's clearly different from the voting base we currently have in practice.
> We have to rely on the > same voting base to change the voting base. I don't see how voting on > all other RFCs is fine, but voting on this one isn't. >
Reality is I don't think it's fine for other RFCs either. I'm not claiming we should revisit each and every past RFC and start backtracking retroactively - but if we are to change the rules, we should do so comprehensively and fix this long outstanding issue.
> > You mentioned that you don't see why the two issues are > > interlinked - and you may be right, it's more that one is dependent on > the > > other. Voting eligibility is the first question we should answer, and it > > should only be followed by the voting rules themselves. > > We currently have an answer to voting eligibility. It's one you may > not like, but changing that is completely independent of changing > voting margins.
Again, in my opinion the answer we have is a de-facto answer that is both fundamentally flawed (that's the opinion part), but also entirely inconsistent with both the intention and text of the Voting RFC that is currently in effect (that's not a matter of opinion, that's fact). It also not completely independent. It has to do with the relative power of the code contributors, vs. folks who aren't code contributors who presently have a vote even though they're not supposed to have one based on the rules agreed upon back in the day. Zeev

Pierre Joye

7 years ago
On Thu, Feb 7, 2019 at 3:39 PM Zeev Suraski <zeev@php.net> wrote:
> It has to do with the relative power > of the code contributors, vs. folks who aren't code contributors who > presently have a vote even though they're not supposed to have one based on > the rules agreed upon back in the day.
This is not correct. I am not sure you read my other reply in the other thread (please do if not). The "must contribute code to have rights to vote" is not what we tried to achieve. Best,
-- Pierre @pierrejoye | http://www.libgd.org

Zeev Suraski

7 years ago
On Thu, Feb 7, 2019 at 10:42 AM Pierre Joye <pierre.php@gmail.com> wrote:
> On Thu, Feb 7, 2019 at 3:39 PM Zeev Suraski <zeev@php.net> wrote: > > > It has to do with the relative power > > of the code contributors, vs. folks who aren't code contributors who > > presently have a vote even though they're not supposed to have one based > on > > the rules agreed upon back in the day. > > This is not correct. I am not sure you read my other reply in the > other thread (please do if not).
I read it, and I didn't find anywhere something that contradicted this.
> The "must contribute code to have > rights to vote" is not what we tried to achieve.
Nor is it what I'm presently trying to achieve either (at least that's not my preferred outcome at this point). Again, there are two categories of people defined as eligible voters: First: "People with php.net VCS accounts that have contributed code to PHP" The intention here is quite clear. People that have contributed "code to PHP". Specifically, it's clearly a qualifier for "People with php.net VCS accounts", i.e., this is a subgroup of those who have VCS accounts - specifically ones that have contributed code to PHP. Second: "Representatives from the PHP community, that will be chosen by those with php.net VCS accounts - Lead developers of PHP based projects (frameworks, cms, tools, etc.) - regular participant of internals discussions" The intention here is also quite clear - add non-code-contributors to have votes as well. However, in terms of how we do it - it's awfully laconic (to be honest I never expected it to just pass as-is - it was roughly at the qualify of a first draft - but it did). The intent was to have some sort of representation of the outside world in the actual votes (and not just in the discussions), instead of having only the code contributors eligible for voting. The intent was still very much to keep the balance of power such that the actual code contributors would have most of the say - as the word 'representatives' implies. However, we never went ahead with the process of choosing these folks anyway. So while I completely agree with you that we didn't try to achieve a "must contribute code to have rights to vote", we did try to achieve a situation where those who contribute code have (as a collective) the most influence. And we certainly didn't try to achieve a "having a VCS account gives you a vote". The 2nd group never materialized - we never went through any sort of process of choosing representatives (mainly because there was no such process). The first group was mis-implemented because it was simple to do in the Wiki - and the rest is history. I still think that at a fundamental level, what we agreed on in 2011 makes sense. The core group should be those who contribute code to PHP (potentially including PECL). On top of that - we need to either figure out the mechanism that we neglected to specify back in 2011, or give up on it officially. As I mentioned previously on this thread - I'm undecided on this matter, but primarily because I'm not sure what this mechanism could look like (even though I have some thoughts on the subject). If we can come up with a good mechanism - I think it's generally a good idea. Zeev

Rowan Collins

7 years ago
On 7 February 2019 08:38:54 GMT+00:00, Zeev Suraski <zeev@php.net> wrote:
>> It's the only definition we currently have. > >That's not exactly true. We have the definition that was actually >agreed >upon in the original Voting RFC, and while it's hardly great - it's >clearly >different from the voting base we currently have in practice.
Perhaps we can agree that, right now, it's the only *practical* definition we have. I was chatting offline about this, and it was pointed out that it's like a country (peacefully) adopting a new constitution: if the old constitution requires a vote to amend, those are the voting rules followed, even if they're completely different from the new constitution. To extend the metaphor, the current "constitution" for PHP RFCs is a de facto one based on precedent, which has evolved due to ambiguities in the previous written one. I'm not sure anyone has the authority to throw away that precedent and reinterpret the older document. Regards,
-- Rowan Collins [IMSoP]

Dmitry Stogov

7 years ago
On 2/6/19 11:50 AM, Nikita Popov wrote:
> On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins <krakjoe@gmail.com> wrote: > >> Afternoon internals, >> >> Some time ago I brought up for discussion: >> https://wiki.php.net/rfc/abolish-narrow-margins >> >> I intend to bring this up for vote in the next few days. >> >> Cheers >> Joe >> > > After one day of heated discussion this thread has died down again. I'd > like to make sure that there are no further concerns here before this goes > to vote. > > Most of the discussion here has been around the question of whether or not > this should be part of Zeev's RFC (and it doesn't look like we're going to > agree on that one), but there has been little further discussion of the > proposal itself. I guess that means it's fairly uncontroversial. > > As far as I can see the only difference between this proposal and Zeev's > (as far as voting margins are concerned), is that this RFC requires a 2/3 > majority, while Zeev's proposal excludes "PHP Packaging Decisions" and only > requires a simple majority for them. > > There has been some brief discussion about this, with the following mail > from Stas: > >> 1. Do we really need different classification of changes? I think having >> one single vote procedure would have larger benefit, and RFC that fails >> 2/3 requirement would be suspect anyway. RFCs can have parts - "whether >> we do it" and "how exactly we do it" - the former would be 2/3 >> requirement, the latter can be simple plurality even - e.g. if we decide >> to have an extension for libfoobar, that should have 2/3 vote, but then >> decision between whether to name it foobar or barfoo can be decided by >> majority or plurality. > > And Zeev's response: > >> I think we do. There are decisions where a 2/3 majority requirement makes >> no sense, as the vote itself is about a choice between two options that > are >> on the table, as opposed to deciding whether to do something or not. >> There aren't many such cases, but when they do occur - they tend to be >> important. >> >> The most obvious case I have in mind is that of the choice between PHP 6 >> and 7. It doesn't expose us to any future commitments, doesn't change the >> language - it's arguably almost a marketing decision. Similarly, if we >> decide to change our release schedule, I don't see why that should require >> a 2/3 majority. The 'bias for the status quo', which is the main reason > we >> have the super majority requirement to begin with, doesn't really play a >> role here - as it bears no long term commitment. > > I'll add my own response here. I agree with Stas that it is preferable to > have a single voting procedure and don't think that "packaging decisions" > should be special cased. This is not just to in the interest of having > simple rules, but also because I disagree with the premise that packaging > decisions are somehow less important than changes to PHP or do not have > future commitments. For example, extending support for a release by > multiple years (a question that will probably come up for PHP 7.4), is a > quite serious commitment of resources that should not be decided on a > narrow margin. > > More importantly, while our past RFCs in the area of "packaging" have not > been particularly major, that's isn't a property inherent to the category. > For example, a proposal to introduce regular LTS releases, or to make other > major changes to our release scheduling, should certainly be subject to a > 2/3 majority. In each category (whether it's changes to PHP or the release > process) there will always be more and less significant RFCs, and it's hard > to draw a good line between them (we failed spectacularly trying to due > that with "language changes"). I think it is better to err on the side of > being conservative and require a 2/3 majority for everything, especially as > it also obviates any arguments as to what requires or doesn't require a > certain majority.
First, take the words from this RFC: "Anything merged into php-src is by definition a core part of PHP, regardless of the folder it goes into, or whether it has direct implications for our users. This is not a debatable fact: If it is distributed with PHP, it is core software". Does this mean that every merge into php-src requires vote? If not, why this sentence is here? Second, many significant internal improvements don't affect PHP behavior at all. Usually, they affect just few core developers and few third-party extensions maintainers. Should this really require super majority of all the voters? Or we can avoid voting, instead? We currently have voting rules, that more or less work. In case, anyone like to change them, it would be better to present new rules as a "DIFF" on top of existing ones (in the most possible compact, clear and formal way). Then we may vote on the whole "DIFF", or each change separately. I wouldn't vote for changes of rules without clear context. I hate politics, and wouldn't like to participate in this discussion :( Thanks. Dmitry.

Nikita Popov

7 years ago
On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov <dmitry@zend.com> wrote:
> > > On 2/6/19 11:50 AM, Nikita Popov wrote: > > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins <krakjoe@gmail.com> wrote: > > > >> Afternoon internals, > >> > >> Some time ago I brought up for discussion: > >> https://wiki.php.net/rfc/abolish-narrow-margins > >> > >> I intend to bring this up for vote in the next few days. > >> > >> Cheers > >> Joe > >> > > > > After one day of heated discussion this thread has died down again. I'd > > like to make sure that there are no further concerns here before this > goes > > to vote. > > > > Most of the discussion here has been around the question of whether or > not > > this should be part of Zeev's RFC (and it doesn't look like we're going > to > > agree on that one), but there has been little further discussion of the > > proposal itself. I guess that means it's fairly uncontroversial. > > > > As far as I can see the only difference between this proposal and Zeev's > > (as far as voting margins are concerned), is that this RFC requires a 2/3 > > majority, while Zeev's proposal excludes "PHP Packaging Decisions" and > only > > requires a simple majority for them. > > > > There has been some brief discussion about this, with the following mail > > from Stas: > > > >> 1. Do we really need different classification of changes? I think having > >> one single vote procedure would have larger benefit, and RFC that fails > >> 2/3 requirement would be suspect anyway. RFCs can have parts - "whether > >> we do it" and "how exactly we do it" - the former would be 2/3 > >> requirement, the latter can be simple plurality even - e.g. if we decide > >> to have an extension for libfoobar, that should have 2/3 vote, but then > >> decision between whether to name it foobar or barfoo can be decided by > >> majority or plurality. > > > > And Zeev's response: > > > >> I think we do. There are decisions where a 2/3 majority requirement > makes > >> no sense, as the vote itself is about a choice between two options that > > are > >> on the table, as opposed to deciding whether to do something or not. > >> There aren't many such cases, but when they do occur - they tend to be > >> important. > >> > >> The most obvious case I have in mind is that of the choice between PHP 6 > >> and 7. It doesn't expose us to any future commitments, doesn't change > the > >> language - it's arguably almost a marketing decision. Similarly, if we > >> decide to change our release schedule, I don't see why that should > require > >> a 2/3 majority. The 'bias for the status quo', which is the main reason > > we > >> have the super majority requirement to begin with, doesn't really play a > >> role here - as it bears no long term commitment. > > > > I'll add my own response here. I agree with Stas that it is preferable to > > have a single voting procedure and don't think that "packaging decisions" > > should be special cased. This is not just to in the interest of having > > simple rules, but also because I disagree with the premise that packaging > > decisions are somehow less important than changes to PHP or do not have > > future commitments. For example, extending support for a release by > > multiple years (a question that will probably come up for PHP 7.4), is a > > quite serious commitment of resources that should not be decided on a > > narrow margin. > > > > More importantly, while our past RFCs in the area of "packaging" have not > > been particularly major, that's isn't a property inherent to the > category. > > For example, a proposal to introduce regular LTS releases, or to make > other > > major changes to our release scheduling, should certainly be subject to a > > 2/3 majority. In each category (whether it's changes to PHP or the > release > > process) there will always be more and less significant RFCs, and it's > hard > > to draw a good line between them (we failed spectacularly trying to due > > that with "language changes"). I think it is better to err on the side of > > being conservative and require a 2/3 majority for everything, especially > as > > it also obviates any arguments as to what requires or doesn't require a > > certain majority. > > First, take the words from this RFC: "Anything merged into php-src is by > definition a core part of PHP, regardless of the folder it goes into, or > whether it has direct implications for our users. This is not a > debatable fact: If it is distributed with PHP, it is core software". > > Does this mean that every merge into php-src requires vote? > If not, why this sentence is here? > > Second, many significant internal improvements don't affect PHP behavior > at all. Usually, they affect just few core developers and few > third-party extensions maintainers. Should this really require super > majority of all the voters? Or we can avoid voting, instead? > > We currently have voting rules, that more or less work. > > In case, anyone like to change them, it would be better to present new > rules as a "DIFF" on top of existing ones (in the most possible compact, > clear and formal way). Then we may vote on the whole "DIFF", or each > change separately. > > I wouldn't vote for changes of rules without clear context. > I hate politics, and wouldn't like to participate in this discussion :( >
Thanks for the feedback. I have added a new section to the RFC with the precise change that will be applied to the voting RFC: https://wiki.php.net/rfc/abolish-narrow-margins#normative_text This is the whole change and nothing else will change. It is exclusively about requiring 2/3 majority for the main RFC vote. It does not change anything about the kind of changes that need an RFC, and certainly doesn't require RFCs or votes for every merge... Probably the rest of the RFC text should also be cleaned up a bit, as I agree that the focus on "merges" is confusing (not all RFCs even have an implementation at the time of vote.) Nikita

Joe Watkins

7 years ago
Afternoon Dmitry, Nikita, I've cleaned that up to read "changes to PHP" rather than talking about merges, apologies for the confusion, just used the wrong words. To re-iterate what Nikita said, this is not about changing what requires an RFC, and not about forcing every change to require an RFC; We're all very aware that there is an almost constant stream of minor improvements committed by core maintainers that don't require RFC, and this RFC does not seek to stand in your way. Cheers Joe On Wed, 6 Feb 2019 at 17:31, Nikita Popov <nikita.ppv@gmail.com> wrote:

Dmitry Stogov

7 years ago
On 2/6/19 8:28 PM, Joe Watkins wrote:
> Afternoon Dmitry, Nikita, > > I've cleaned that up to read "changes to PHP" rather than talking about > merges, apologies for the confusion, just used the wrong words. > > To re-iterate what Nikita said, this is not about changing what requires > an RFC, and not about forcing every change to require an RFC; We're all > very aware that there is an almost constant stream of minor improvements > committed by core maintainers that don't require RFC, and this RFC does > not seek to stand in your way.
The "Normative text" section looks clear now. I would remove all the rest of the "Proposal" section, assuming that it's reflected in the "Normative text", anyway. Additional note (unrelated to this RFC, but related to RFC process). It would be great to define some formal procedure of approval of RFC implementation patches. - When a patch is required and good enough, to turn RFC into voting? - When a patch of accepted RFC may (or may not) be merged? Currently, this procedure is completely informal. Thanks. Dmitry.

Joe Watkins

7 years ago
Morning Dmitry, I've cleaned up the proposal section to refer to the normative text section, but it remains to make clear that we are applying these rules to all RFCs (including policy amendments). Cheers Joe On Wed, 6 Feb 2019 at 22:12, Dmitry Stogov <dmitry@zend.com> wrote:

Stas Malyshev

7 years ago
Hi!
> Thanks for the feedback. I have added a new section to the RFC with the > precise change that will be applied to the voting RFC: > https://wiki.php.net/rfc/abolish-narrow-margins#normative_text
I think explaining the changes clearly is a good addition, but I wonder if we should be retroactively editing the RFCs themselves. Maybe instead we should have separate page on wiki - https://wiki.php.net/voting akin to https://wiki.php.net/security - and edit that? Of course, wikis have history, but it seems to be editing the RFC itself makes it harder to see which part is current and which part is original and what was originally proposed, so that it may happen that RFC is nominally attributed to one person, but its content has eventually nothing to do with what that person proposed and written by somebody else.
-- Stas Malyshev smalyshev@gmail.com