RFC Abolish Narrow Margins

6 years ago by Joe Watkins — view source — reply

unread

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

6 years ago by Zeev Suraski — view source — reply

unread

-----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

6 years ago by Joe Watkins — view source — reply

unread

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

-----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

6 years ago by Zeev Suraski — view source — reply

unread

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

-----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

6 years ago by Joe Watkins — view source — reply

unread

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

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

-----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

6 years ago by Zeev Suraski — view source — reply

unread

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

6 years ago by Joe Watkins — view source — reply

unread

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

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

6 years ago by Dmitry Stogov — view source — reply

unread

Hi Joe,

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.

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

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

6 years ago by Zeev Suraski — view source — reply

unread

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

6 years ago by Joe Watkins — view source — reply

unread

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

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

6 years ago by Dmitry Stogov — view source — reply

unread

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.

Do you understand what is PHP callback in context of FFI?
In the following example, it's used to override zend_write by PHP
function, but FFI can't know when this callback is not used by C
anymore, and keeps it until the end of request.

<?php
$zend = FFI::cdef("
typedef int (*zend_write_func_t)(const char *str, size_t str_length);
extern zend_write_func_t zend_write;
");

$orig_zend_write = clone $zend->zend_write;
$zend->zend_write = function($str, $len) {
global $orig_zend_write;
$orig_zend_write("{\n\t", 3);
$ret = $orig_zend_write($str, $len);
$orig_zend_write("}\n", 2);
return $ret;
};
echo "Hello World!\n";
$zend->zend_write = $orig_zend_write;
?>

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.

There is the same issue with FFI for LuaJIT.
I'm not sure if Python CFFI supports callbacks.

Aside from whatever technical issues I may have misinterpreted or
misidentified, these are not my main objections to it being merged.

I got it.

Thanks. Dmitry.

Cheers
Joe

On Thu, 31 Jan 2019 at 17:20, Zeev Suraski <zeev@php.net
mailto:zeev@php.net> wrote:

On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov <dmitry@zend.com
<mailto: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

6 years ago by Zeev Suraski — view source — reply

unread

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

6 years ago by Nikita Popov — view source — reply

unread

-----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

6 years ago by Zeev Suraski — view source — reply

unread

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

6 years ago by Nikita Popov — view source — reply

unread

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?

6 years ago by Zeev Suraski — view source — reply

unread

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

6 years ago by Stanislav Malyshev — view source — reply

unread

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

6 years ago by Joe Watkins — view source — reply

unread

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

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

6 years ago by Nikita Popov — view source — reply

unread

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

6 years ago by Zeev Suraski — view source — reply

unread

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

6 years ago by Andrey Andreev — view source — reply

unread

Hi,

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.

6 years ago by Nikita Popov — view source — reply

unread

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:

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

6 years ago by Zeev Suraski — view source — reply

unread

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

6 years ago by Dmitry Stogov — view source — reply

unread

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:

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

6 years ago by Nikita Popov — view source — reply

unread

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:

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

6 years ago by Joe Watkins — view source — reply

unread

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

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:

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

6 years ago by Niklas Keller — view source — reply

unread

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

6 years ago by Stanislav Malyshev — view source — reply

unread

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

6 years ago by Dmitry Stogov — view source — reply

unread

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.

Cheers
Joe

On Wed, 6 Feb 2019 at 17:31, Nikita Popov <nikita.ppv@gmail.com
mailto:nikita.ppv@gmail.com> wrote:

On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov <dmitry@zend.com
<mailto:dmitry@zend.com>> wrote:



    
     > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins
    <krakjoe@gmail.com <mailto: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

6 years ago by Pierre Joye — view source — reply

unread

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

6 years ago by Joe Watkins — view source — reply

unread

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

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.

Cheers
Joe

On Wed, 6 Feb 2019 at 17:31, Nikita Popov <nikita.ppv@gmail.com
mailto:nikita.ppv@gmail.com> wrote:

On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov <dmitry@zend.com
<mailto:dmitry@zend.com>> wrote:



    
     > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins
    <krakjoe@gmail.com <mailto: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

6 years ago by Zeev Suraski — view source — reply

unread

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

6 years ago by Zeev Suraski — view source — reply

unread

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

6 years ago by Rowan Collins — view source — reply

unread

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]