Re: [PHP-DEV] RFC Abolish Narrow Margins

[Rowan Collins]

On 7 February 2019 08:38:54 GMT+00:00, Zeev Suraski  wrote:
>> It's the only definition we currently have.
>
>That's not exactly true.  We have the definition that was actually
>agreed
>upon in the original Voting RFC, and while it's hardly great - it's
>clearly
>different from the voting base we currently have in practice.

Perhaps we can agree that, right now, it's the only *practical* definition we 
have.

I was chatting offline about this, and it was pointed out that it's like a 
country (peacefully) adopting a new constitution: if the old constitution 
requires a vote to amend, those are the voting rules followed, even if they're 
completely different from the new constitution. 

To extend the metaphor, the current "constitution" for PHP RFCs is a de facto 
one based on precedent, which has evolved due to ambiguities in the previous 
written one. I'm not sure anyone has the authority to throw away that precedent 
and reinterpret the older document.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Feb 7, 2019 at 10:42 AM Pierre Joye  wrote:

> On Thu, Feb 7, 2019 at 3:39 PM Zeev Suraski  wrote:
>
> >  It has to do with the relative power
> > of the code contributors, vs. folks who aren't code contributors who
> > presently have a vote even though they're not supposed to have one based
> on
> > the rules agreed upon back in the day.
>
> This is not correct. I am not sure you read my other reply in the
> other thread (please do if not).


I read it, and I didn't find anywhere something that contradicted this.


> The "must contribute code to have
> rights to vote" is not what we tried to achieve.


Nor is it what I'm presently trying to achieve either (at least that's not
my preferred outcome at this point).

Again, there are two categories of people defined as eligible voters:

First:
"People with php.net VCS accounts that have contributed code to PHP"
The intention here is quite clear.  People that have contributed "code to
PHP".  Specifically, it's clearly a qualifier for "People with php.net VCS
accounts", i.e., this is a subgroup of those who have VCS accounts -
specifically ones that have contributed code to PHP.

Second:
"Representatives from the PHP community, that will be chosen by those with
php.net VCS accounts

   - Lead developers of PHP based projects (frameworks, cms, tools, etc.)
   - regular participant of internals discussions"

The intention here is also quite clear - add non-code-contributors to have
votes as well.  However, in terms of how we do it - it's awfully laconic
(to be honest I never expected it to just pass as-is - it was roughly at
the qualify of a first draft - but it did).  The intent was to have some
sort of representation of the outside world in the actual votes (and not
just in the discussions), instead of having only the code contributors
eligible for voting.  The intent was still very much to keep the balance of
power such that the actual code contributors would have most of the say -
as the word 'representatives' implies.  However, we never went ahead with
the process of choosing these folks anyway.

So while I completely agree with you that we didn't try to achieve a "must
contribute code to have rights to vote", we did try to achieve a situation
where those who contribute code have (as a collective) the most influence.
And we certainly didn't try to achieve a "having a VCS account gives you a
vote".  The 2nd group never materialized - we never went through any sort
of process of choosing representatives (mainly because there was no such
process).  The first group was mis-implemented because it was simple to do
in the Wiki - and the rest is history.

I still think that at a fundamental level, what we agreed on in 2011 makes
sense.  The core group should be those who contribute code to PHP
(potentially including PECL).  On top of that - we need to either figure
out the mechanism that we neglected to specify back in 2011, or give up on
it officially.  As I mentioned previously on this thread - I'm undecided on
this matter, but primarily because I'm not sure what this mechanism could
look like (even though I have some thoughts on the subject).  If we can
come up with a good mechanism - I think it's generally a good idea.

Zeev

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Pierre Joye]

On Thu, Feb 7, 2019 at 3:39 PM Zeev Suraski  wrote:

>  It has to do with the relative power
> of the code contributors, vs. folks who aren't code contributors who
> presently have a vote even though they're not supposed to have one based on
> the rules agreed upon back in the day.

This is not correct. I am not sure you read my other reply in the
other thread (please do if not). The "must contribute code to have
rights to vote" is not what we tried to achieve.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Wed, Feb 6, 2019 at 9:06 PM Niklas Keller  wrote:

> > I'll reiterate my main two issues with this RFC:
> > - I do think that we need 50%+1 votes for certain decisions.  Naming the
> > next version of PHP, or even deciding to release it outside of the yearly
> > cycle should not require a 2/3 vote.  It's not so much erring on the side
> > of being conservative - it's enforcing a bias for status-quo that simply
> > doesn't exist in these issues.  Is it the end of the world that we won't
> > have it?  No, but it's better that we would.
> > - More importantly, the voting base issue must be solved before we change
> > the voting rules.  I find it extremely problematic process-wise that
> we'll
> > change the rules using a voting base that was never defined to be valid
> in
> > the first place.
>
> It's the only definition we currently have.


That's not exactly true.  We have the definition that was actually agreed
upon in the original Voting RFC, and while it's hardly great - it's clearly
different from the voting base we currently have in practice.


> We have to rely on the
> same voting base to change the voting base. I don't see how voting on
> all other RFCs is fine, but voting on this one isn't.
>

Reality is I don't think it's fine for other RFCs either.  I'm not claiming
we should revisit each and every past RFC and start backtracking
retroactively - but if we are to change the rules, we should do so
comprehensively and fix this long outstanding issue.


> > You mentioned that you don't see why the two issues are
> > interlinked - and you may be right, it's more that one is dependent on
> the
> > other.  Voting eligibility is the first question we should answer, and it
> > should only be followed by the voting rules themselves.
>
> We currently have an answer to voting eligibility. It's one you may
> not like, but changing that is completely independent of changing
> voting margins.


Again, in my opinion the answer we have is a de-facto answer that is both
fundamentally flawed (that's the opinion part), but also entirely
inconsistent with both the intention and text of the Voting RFC that is
currently in effect (that's not a matter of opinion, that's fact).
It also not completely independent.  It has to do with the relative power
of the code contributors, vs. folks who aren't code contributors who
presently have a vote even though they're not supposed to have one based on
the rules agreed upon back in the day.

Zeev

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Morning Dmitry,

I've cleaned up the proposal section to refer to the normative text
section, but it remains to make clear that we are applying these rules to
all RFCs (including policy amendments).

Cheers
Joe

On Wed, 6 Feb 2019 at 22:12, Dmitry Stogov  wrote:

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

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Dmitry Stogov]

On 2/6/19 8:28 PM, Joe Watkins wrote:
> Afternoon Dmitry, Nikita,
> 
> I've cleaned that up to read "changes to PHP" rather than talking about 
> merges, apologies for the confusion, just used the wrong words.
> 
> To re-iterate what Nikita said, this is not about changing what requires 
> an RFC, and not about forcing every change to require an RFC; We're all 
> very aware that there is an almost constant stream of minor improvements 
> committed by core maintainers that don't require RFC, and this RFC does 
> not seek to stand in your way.

The "Normative text" section looks clear now.
I would remove all the rest of the "Proposal" section, assuming that 
it's reflected in the "Normative text", anyway.

Additional note (unrelated to this RFC, but related to RFC process).
It would be great to define some formal procedure of approval of RFC 
implementation patches.
- When a patch is required and good enough, to turn RFC into voting?
- When a patch of accepted RFC may (or may not) be merged?

Currently, this procedure is completely informal.

Thanks. Dmitry.




> Cheers
> Joe
> 
> On Wed, 6 Feb 2019 at 17:31, Nikita Popov  > wrote:
> 
> On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/6/19 11:50 AM, Nikita Popov wrote:
>  > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins
> mailto:krak...@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 

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Stanislav Malyshev]

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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Niklas Keller]

> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon Dmitry, Nikita,

I've cleaned that up to read "changes to PHP" rather than talking about
merges, apologies for the confusion, just used the wrong words.

To re-iterate what Nikita said, this is not about changing what requires an
RFC, and not about forcing every change to require an RFC; We're all very
aware that there is an almost constant stream of minor improvements
committed by core maintainers that don't require RFC, and this RFC does not
seek to stand in your way.

Cheers
Joe

On Wed, 6 Feb 2019 at 17:31, Nikita Popov  wrote:

> On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov  wrote:
>
>>
>>
>> On 2/6/19 11:50 AM, Nikita Popov wrote:
>> > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins  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 

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Nikita Popov]

On Wed, Feb 6, 2019 at 4:38 PM Dmitry Stogov  wrote:

>
>
> On 2/6/19 11:50 AM, Nikita Popov wrote:
> > On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins  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 

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Dmitry Stogov]

On 2/6/19 11:50 AM, Nikita Popov wrote:
> On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins  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 

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Fri, Feb 1, 2019 at 1:38 PM Nikita Popov  wrote:

> On Fri, Feb 1, 2019 at 6:16 AM Stanislav Malyshev 
> 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

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Wed, Feb 6, 2019 at 10:50 AM Nikita Popov  wrote:

> More importantly, while our past RFCs in the area of "packaging" have not
> been particularly major, that's isn't a property inherent to the category.
> For example, a proposal to introduce regular LTS releases, or to make other
> major changes to our release scheduling, should certainly be subject to a
> 2/3 majority. In each category (whether it's changes to PHP or the release
> process) there will always be more and less significant RFCs, and it's hard
> to draw a good line between them (we failed spectacularly trying to due
> that with "language changes"). I think it is better to err on the side of
> being conservative and require a 2/3 majority for everything, especially as
> it also obviates any arguments as to what requires or doesn't require a
> certain majority.


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

In addition, rushing this RFC for a vote while the discussion of the more
comprehensive approach is in motion is quite questionable in my opinion.

Zeev





>

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Nikita Popov]

On Thu, Jan 31, 2019 at 1:59 PM Joe Watkins  wrote:

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

After one day of heated discussion this thread has died down again. I'd
like to make sure that there are no further concerns here before this goes
to vote.

Most of the discussion here has been around the question of whether or not
this should be part of Zeev's RFC (and it doesn't look like we're going to
agree on that one), but there has been little further discussion of the
proposal itself. I guess that means it's fairly uncontroversial.

As far as I can see the only difference between this proposal and Zeev's
(as far as voting margins are concerned), is that this RFC requires a 2/3
majority, while Zeev's proposal excludes "PHP Packaging Decisions" and only
requires a simple majority for them.

There has been some brief discussion about this, with the following mail
from Stas:

> 1. Do we really need different classification of changes? I think having
> one single vote procedure would have larger benefit, and RFC that fails
> 2/3 requirement would be suspect anyway. RFCs can have parts - "whether
> we do it" and "how exactly we do it" - the former would be 2/3
> requirement, the latter can be simple plurality even - e.g. if we decide
> to have an extension for libfoobar, that should have 2/3 vote, but then
> decision between whether to name it foobar or barfoo can be decided by
> majority or plurality.

And Zeev's response:

> I think we do.  There are decisions where a 2/3 majority requirement makes
> no sense, as the vote itself is about a choice between two options that
are
> on the table, as opposed to deciding whether to do something or not.
> There aren't many such cases, but when they do occur - they tend to be
> important.
>
> The most obvious case I have in mind is that of the choice between PHP 6
> and 7.  It doesn't expose us to any future commitments, doesn't change the
> language - it's arguably almost a marketing decision.  Similarly, if we
> decide to change our release schedule, I don't see why that should require
> a 2/3 majority.  The 'bias for the status quo', which is the main reason
we
> have the super majority requirement to begin with, doesn't really play a
> role here - as it bears no long term commitment.

I'll add my own response here. I agree with Stas that it is preferable to
have a single voting procedure and don't think that "packaging decisions"
should be special cased. This is not just to in the interest of having
simple rules, but also because I disagree with the premise that packaging
decisions are somehow less important than changes to PHP or do not have
future commitments. For example, extending support for a release by
multiple years (a question that will probably come up for PHP 7.4), is a
quite serious commitment of resources that should not be decided on a
narrow margin.

More importantly, while our past RFCs in the area of "packaging" have not
been particularly major, that's isn't a property inherent to the category.
For example, a proposal to introduce regular LTS releases, or to make other
major changes to our release scheduling, should certainly be subject to a
2/3 majority. In each category (whether it's changes to PHP or the release
process) there will always be more and less significant RFCs, and it's hard
to draw a good line between them (we failed spectacularly trying to due
that with "language changes"). I think it is better to err on the side of
being conservative and require a 2/3 majority for everything, especially as
it also obviates any arguments as to what requires or doesn't require a
certain majority.

Nikita

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Nikita Popov]

On Fri, Feb 1, 2019 at 6:16 AM Stanislav Malyshev 
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

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Morning Stas, and all,

This discussion was ... a mess, partly my fault, I suppose.

I said I was going to bring it up for voting quickly on the say so of
Nikita, and because it feels urgent to us, you can guess our reasons for
that.

I'm not going to argue back and forth for the next week about the reasons
we think this is important.

In a week, let's say next Friday, to be totally fair, this RFC will go to
vote.

Cheers
Joe

On Fri, 1 Feb 2019 at 06:16, Stanislav Malyshev  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.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Stanislav Malyshev]

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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Andrey Andreev]

Hi,

On Thu, Jan 31, 2019 at 5:28 PM Zeev Suraski  wrote:
>
> Secondly - the threshold and voting eligibility are not, in any way,
> independent.  They're two fundamental aspects of the same topic - how votes
> take place.  A 2/3 majority out of a subset of ~200-300 people is very
> different from a 2/3 majority out of a potential group of several thousand
> people
>

Does that really matter though? Your own proposal includes the 2/3
rule and I don't think you're saying 50%+1 is OK now, so what
difference does it make?
I don't see a reason why this RFC, which looks almost like just a
formality, should be bundled with something way bigger and
controversial.

Cheers,
Andrey.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 7:00 PM Nikita Popov  wrote:

> Let me reply to the last point first, because I think that's really the
> crux here: The issue is not that this RFC is very urgent per se, it's that
> it has already been delayed numerous times and it is imperative that we
> prevent that from happening again. Since this issue was first raised, a
> number of RFCs have passed with narrow voting margins. Every time that
> happens, I think "damn, why didn't we go through with the voting threshold
> RFC?"
>
> This RFC has been delayed for various reasons in the past -- those reasons
> sounded good at the time, but the end effect is still the same: RFCs being
> accepted with unreasonable margins. If we delay this again and it turns out
> that your competing RFC stays in limbo for the next two years, or is simply
> not accepted due to changes unrelated to voting margins, I would consider
> that to be quite unfortunate.
>

I've had similar issues with other aspects of the shortcoming of the 2011
Voting RFC.  The 50%+1 vs 2/3 is really just one issue - it's an important
one, but just one - and it doesn't live in vacuum.  It's interrelated to
other issues.


> If you have concerns with the details of the rules outlined in this RFC,
> I'm sure that Joe is open to discussing them. But let's please make sure
> that this particular question is resolved in a timely manner, which I think
> requires it to be tackled separately from other issues.
>

To me, changing the margins is like placing a band-aid on a gunshot wound.
Or perhaps to be more fair, it's to start surgery on wound, but then
stopping a 3rd way through or so.
Unless the RFC is extended to cover all the key shortcomings of the 2011
Voting RFC, then it's a superficial fix that I can't be in favor of.
 Rushing it through bears the hallmarks of the issues that plagued the 2011
Voting RFC - putting something together quickly, not trying to think
through all of the different scenarios and consequently not providing a
comprehensive solution.

Is the 2011 Voting RFC + permanent 2/3 margins still deeply flawed?  I'd
say absolutely yes.  Then let's think on how we fix it holistically.

If your concern is that RFCs would pass under this low margin as we debate
- why not call for a 30 day pause on RFC votes altogether (extensible by
another 30 days assuming there's still a healthy discussion), not just for
JIT?  I'm all for it.  We have the time and apparently now also the
inclination, let's finally settle this thing and make it right.

Zeev

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Nikita Popov]

On Thu, Jan 31, 2019 at 4:27 PM Zeev Suraski  wrote:

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

Let me reply to the last point first, because I think that's really the
crux here: The issue is not that this RFC is very urgent per se, it's that
it has already been delayed numerous times and it is imperative that we
prevent that from happening again. Since this issue was first raised, a
number of RFCs have passed with narrow voting margins. Every time that
happens, I think "damn, why didn't we go through with the voting threshold
RFC?"

This RFC has been delayed for various reasons in the past -- those reasons
sounded good at the time, but the end effect is still the same: RFCs being
accepted with unreasonable margins. If we delay this again and it turns out
that your competing RFC stays in limbo for the next two years, or is simply
not accepted due to changes unrelated to voting margins, I would consider
that to be quite unfortunate.

If you have concerns with the details of the rules outlined in this RFC,
I'm sure that Joe is open to discussing them. But let's please make sure
that this particular question is resolved in a timely manner, which I think
requires it to be tackled separately from other issues.

Regarding your point about implementation issues: I'm not really sure I
understand it. Generally implementation issues are decided by a small group
of people (usually Dmitry, Bob and myself), often without even going
through the internals list. Of course very large changes (like say phpng)
should go through the RFC process simply because they affect many more
people (in particular also extension authors). Apart from that, I'm not
sure which other "implementation" RFCs you have in mind here.

Regards,
Nikita

PS: I think this thread went thoroughly off track and now mostly discusses
the FFI extension rather than this RFC ... Maybe that should be moved
elsewhere?

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Dmitry Stogov]

On 1/31/19 7:23 PM, Joe Watkins wrote:
> 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.

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  > wrote:
> 
> 
> 
> On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov  > 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
> 

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 5:56 PM Joe Watkins  wrote:

> When I refer to "you", I really mean you and Dmitry, while you don't have
> a hive mind, you do act as one, or for one another in a lot of cases. If
> I'm wrong about that, I apologise.
>

You are wrong, apology accepted.


> > I would say that Dmitry has by far the best track record of fixing any
> outstanding issues
>
> I would agree, however it was Dmitry that wrote the RFC, and Dmitry that
> said it had leaks ... what am I supposed to think about that ? If someone
> does a patch for /Zend and it leaks or is suboptimal in any way, it does
> not land on Dmitry's say so, but it's okay for him to merge stuff with
> known defects ... I think the problem there is quite clear.
>

See separate reply from both Dmitry and me.  Sounds like a large part of
what brought you to vote against FFI was misunderstanding of the
situation.  Which I guess can still be blamed on the RFC author, but at
least, this concern should be alleviated now.

> Functionality isn't everything.  Very few extensions have a technical
> requirement to be bundled - it's much more of a question of promotion.
>
> So you want to say that for FFI to be used, it had to be included in
> php-src ? That's nonsense, the kind of people who are capable of using FFI
> are also capable of installing an extension.
>

Joe, please, this language is counter-productive. Even more so when you're
first putting words in my mouth, but also without it.  Can we discuss
things politely without telling the other party that they're being
nonsensical?

I did not say that that "it had to be included in php-src in order to be
used".  Neither does ext/mysqli or any other extension for that matter.  I
*did* and *am* saying that it will *promote* its usage.  As is the case
with most promotions - the lack of promotion does not necessarily mean
complete and utter failure, but the presence of promotion may yield better
results than without it.  I very much stand by my statement that bundling
extensions in PHP is predominantly about promotion and ease of use, than it
is about technical requirements.


> From my perspective it had no justification for being merged at all, but
> there were very good reasons to keep it out of php-src not least the slim
> majority on which it was merged.
>

It wasn't such a slim majority, it was 62% IIRC, which is a lot closer to
the 2/3 needed than the 1/2 that was defined for it.  That said, I think
it's sad it didn't clear the vote with a much higher margin - well above
2/3 - and I'm making a cautious bet than misunderstandings around potential
leaks may have had something to do with it, and had it been clear that
these potential "leaks" are in fact an inherent element of FFI, and not a
limitation of the implementation - it would likely have gotten a lot fewer
negative votes.

> I actually agree with you that the fact it didn't clear a 2/3 vote, and
> with a hefty margin - is not very ideal.
>
> So it sounds like we agree here, it was pushed into php-src on an
> unacceptable margin.
>

"Unacceptable" is your statement, not mine.  We're not in a black and white
world - it's grey.  I think that with the current rules, it's 100.0%
acceptable.  Would I prefer that it cleared the vote with a much higher,
80-90% margin?  Yes.

For JIT, which is a much bigger deal in every respect compared to FFI, I
think it makes sense to take a pause and make sure we have our rules in
order before we move forward.

> I categorically disagree that it is an incomplete feature;  I presume
> you're saying this because it currently supports Linux x86/x64?
>
> This sounds disingenuous to me, you are trying to make it sound ready
> before it actually is.
>

 I can't control what it sounds like to you.  I can only control what I
say, and I know that I'm saying it with 100% sincerity based on my view of
the world and the importance of the different deployment platforms in the
PHP space.

>  It's not unusual for complicated pieces of software to first be
> available for specific subsets of platforms, and than gradually be ported
> to others
>
> That's true, but Windows is a core platform for PHP, if you haven't got
> Windows, you got nothing.
>

As the person who made PHP a first class citizen under Windows back in the
day (based on tons of prior work by Shane Caraveo), I wholeheartedly
disagree.

Windows support is not *nearly* as important as Linux support, especially
not when we deal with production systems - which is what JIT is geared at.
Windows it a tiny tiny fraction compared to Linux as far as deployments are
concerned.  The situation is different when we deal with development - but
that's mostly orthogonal to JIT (again, a production feature) - plus recent
trends make it even less of an issue, as even a developer running Windows
is today more likely to be running PHP in a Linux container/VM, than
natively on Windows.

I wouldn't make such a fuss about windows or fancy architectures, if I
> thought there was 

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Hi Zeev, Dmitry,

It is not my only concern, I'm grateful for the clarification whatever.

These are your actual words from the RFC:

> This works, but this functionality is not supported on all libffi
platforms, it is not efficient and leaks resources by the end of request.
It's recommended to minimize the usage of PHP callbacks.

To me, a foreign function interface where one side of the interface sounds
broken and inefficient, according to the author, is scary. I've never
worked with libffi, so don't know if that's normal ... but I think you can
understand my thoughts here.

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

Cheers
Joe

On Thu, 31 Jan 2019 at 17:20, Zeev Suraski  wrote:

>
>
> On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov  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
>

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 6:09 PM Dmitry Stogov  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

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Dmitry Stogov]

Hi Joe,

On 1/31/19 6:56 PM, Joe Watkins wrote:
> Afternoon Zeev,
> 
>> I'll happily take your interpretation of it.  No hard feelings.
> 
> Thanks, you know I don't have another way of being :)
> 
> When I refer to "you", I really mean you and Dmitry, while you don't have a
> hive mind, you do act as one, or for one another in a lot of cases. If I'm
> wrong about that, I apologise.
> 
>> I would say that Dmitry has by far the best track record of fixing any
> outstanding issues
> 
> I would agree, however it was Dmitry that wrote the RFC, and Dmitry that
> said it had leaks ... what am I supposed to think about that ? If someone
> does a patch for /Zend and it leaks or is suboptimal in any way, it does
> not land on Dmitry's say so, but it's okay for him to merge stuff with
> known defects ... I think the problem there is quite clear.

The fact that FFI may leak, is because it uses "unmanaged memory" (like 
in real C). PHP reference counting and GC just can't handle all the 
cases. It's impossible to automatically know what to do with C pointer, 
when we get it from function or another structure. In this case 
programmer have to care about freeing the pointer themselves (like in C).

This is all about the FFI leaks.

Thanks. Dmitry.

> 
>> Functionality isn't everything.  Very few extensions have a technical
> requirement to be bundled - it's much more of a question of promotion.
> 
> So you want to say that for FFI to be used, it had to be included in
> php-src ? That's nonsense, the kind of people who are capable of using FFI
> are also capable of installing an extension. From my perspective it had no
> justification for being merged at all, but there were very good reasons to
> keep it out of php-src not least the slim majority on which it was merged.
> 
>> I actually agree with you that the fact it didn't clear a 2/3 vote, and
> with a hefty margin - is not very ideal.
> 
> So it sounds like we agree here, it was pushed into php-src on an
> unacceptable margin.
> 
>> I categorically disagree that it is an incomplete feature;  I presume
> you're saying this because it currently supports Linux x86/x64?
> 
> This sounds disingenuous to me, you are trying to make it sound ready
> before it actually is.
> 
>>   It's not unusual for complicated pieces of software to first be
> available for specific subsets of platforms, and than gradually be ported
> to others
> 
> That's true, but Windows is a core platform for PHP, if you haven't got
> Windows, you got nothing. I wouldn't make such a fuss about windows or
> fancy architectures, if I thought there was anyone around who could
> actually implement them, as far as I know there isn't and if they are
> unimportant to dmitry and yourself, then it won't get done.
> 
>> I think there were questionable decisions that happened long before
> FFI/JIT, and still, it didn't cross my mind to suddenly change the rules
> for them specifically.
> 
> Check the date on the rfc, nothing is happening suddenly.
> 
>>   I'm not fine with rushing to hastily change the rules (while breaking
> the existing ones) to counter a specific RFC.
> 
> As I have already explained, I'm prompted to act because of a pattern of
> behaviour and decisions that I find questionable, and so do others ... and
> by your own admission, so do you ...
> 
> I should make clear that I think FFI is really cool although I haven't
> found time to play with it yet, and clearly I want us to have a JIT, and
> marvel at the achievement. I can't wait to start reading it (again) and
> trying to understand. This is not about one or two RFCs, but making simple
> changes to give us more confidence in the decisions we are all making, and
> it certainly isn't an attack on you or Dmitry, nothing of the sort ...
> 
> I think we don't really have anything to argue about, and to reiterate, I
> will be taking this RFC to vote.
> 
> Cheers
> Joe
> 
> 
> On Thu, 31 Jan 2019 at 16:13, Zeev Suraski  wrote:
> 
>>
>>
>> On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins  wrote:
>>
>>> Afternoon Zeev,
>>>
>>> I'm going to use unambiguous and direct language to make sure my
>>> intentions
>>> and concerns are communicated clearly, you can either receive this as a
>>> personal attack, or as a contributor being direct, I would prefer the
>>> latter.
>>>
>>
>> I fail to see how in the way it was written it could not be taken as a
>> personal attack, but since you wrote it, I'll happily take your
>> interpretation of it.  No hard feelings.
>>
>>
>>> You pushed FFI into php-src on a simple majority
>>
>>
>> I didn't push FFI.  Yes, it was my idea to invest in it a year or two ago,
>> but Dmitry took it from A to Z.  Contrary to popular belief, we're not the
>> same person, nor do we have a hive mind...
>>
>>
>>> was
>>> incomplete (with leaks),
>>
>>
>> I would say that Dmitry has by far the best track record of fixing any
>> outstanding issues - not only with his code, but with the code of mostly
>> everyone else contributing to PHP, so if 

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon Zeev,

> I'll happily take your interpretation of it.  No hard feelings.

Thanks, you know I don't have another way of being :)

When I refer to "you", I really mean you and Dmitry, while you don't have a
hive mind, you do act as one, or for one another in a lot of cases. If I'm
wrong about that, I apologise.

> I would say that Dmitry has by far the best track record of fixing any
outstanding issues

I would agree, however it was Dmitry that wrote the RFC, and Dmitry that
said it had leaks ... what am I supposed to think about that ? If someone
does a patch for /Zend and it leaks or is suboptimal in any way, it does
not land on Dmitry's say so, but it's okay for him to merge stuff with
known defects ... I think the problem there is quite clear.

> Functionality isn't everything.  Very few extensions have a technical
requirement to be bundled - it's much more of a question of promotion.

So you want to say that for FFI to be used, it had to be included in
php-src ? That's nonsense, the kind of people who are capable of using FFI
are also capable of installing an extension. From my perspective it had no
justification for being merged at all, but there were very good reasons to
keep it out of php-src not least the slim majority on which it was merged.

> I actually agree with you that the fact it didn't clear a 2/3 vote, and
with a hefty margin - is not very ideal.

So it sounds like we agree here, it was pushed into php-src on an
unacceptable margin.

> I categorically disagree that it is an incomplete feature;  I presume
you're saying this because it currently supports Linux x86/x64?

This sounds disingenuous to me, you are trying to make it sound ready
before it actually is.

>  It's not unusual for complicated pieces of software to first be
available for specific subsets of platforms, and than gradually be ported
to others

That's true, but Windows is a core platform for PHP, if you haven't got
Windows, you got nothing. I wouldn't make such a fuss about windows or
fancy architectures, if I thought there was anyone around who could
actually implement them, as far as I know there isn't and if they are
unimportant to dmitry and yourself, then it won't get done.

> I think there were questionable decisions that happened long before
FFI/JIT, and still, it didn't cross my mind to suddenly change the rules
for them specifically.

Check the date on the rfc, nothing is happening suddenly.

>  I'm not fine with rushing to hastily change the rules (while breaking
the existing ones) to counter a specific RFC.

As I have already explained, I'm prompted to act because of a pattern of
behaviour and decisions that I find questionable, and so do others ... and
by your own admission, so do you ...

I should make clear that I think FFI is really cool although I haven't
found time to play with it yet, and clearly I want us to have a JIT, and
marvel at the achievement. I can't wait to start reading it (again) and
trying to understand. This is not about one or two RFCs, but making simple
changes to give us more confidence in the decisions we are all making, and
it certainly isn't an attack on you or Dmitry, nothing of the sort ...

I think we don't really have anything to argue about, and to reiterate, I
will be taking this RFC to vote.

Cheers
Joe


On Thu, 31 Jan 2019 at 16:13, Zeev Suraski  wrote:

>
>
> On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins  wrote:
>
>> Afternoon Zeev,
>>
>> I'm going to use unambiguous and direct language to make sure my
>> intentions
>> and concerns are communicated clearly, you can either receive this as a
>> personal attack, or as a contributor being direct, I would prefer the
>> latter.
>>
>
> I fail to see how in the way it was written it could not be taken as a
> personal attack, but since you wrote it, I'll happily take your
> interpretation of it.  No hard feelings.
>
>
>> You pushed FFI into php-src on a simple majority
>
>
> I didn't push FFI.  Yes, it was my idea to invest in it a year or two ago,
> but Dmitry took it from A to Z.  Contrary to popular belief, we're not the
> same person, nor do we have a hive mind...
>
>
>> was
>> incomplete (with leaks),
>
>
> I would say that Dmitry has by far the best track record of fixing any
> outstanding issues - not only with his code, but with the code of mostly
> everyone else contributing to PHP, so if there's one contributor where this
> isn't something to worry about - that's him.
>
>
>> and had zero justification for being included in
>> php-src - it didn't require any internal API's and can function just fine
>> as a PECL extension
>
>
> Functionality isn't everything.  Very few extensions have a technical
> requirement to be bundled - it's much more of a question of promotion.
>
>
>> still you pushed through with the RFC and it was
>> accepted on a simple majority.
>>
>
> I did not push this RFC in any way, nor did I even try to ask others to
> vote for it (which I would have if I was 'pushing' it).  I actually agree
> with you 

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 4:55 PM Nikita Popov  wrote:

> I agree with Joe here that we should handle the question of voting margins
> separately. Your RFC is a much more comprehensive reform, which contains a
> number of points that look highly controversial to me (such as the eligible
> voter changes). It may take a long time until we reach a satisfactory
> consensus there.
>
> On the other hand, this RFC is very simple and at least to me a complete
> no-brainer. I already use 2/3 majority for all my votes, because I very
> strongly believe that changes to PHP need to be held to a much higher
> standard than a simple majority. It is outright shameful that functionality
> can be added to PHP if 21 vote in favor and 20 against. That's not a
> consensus, that's a complete disagreement.
>
> It's not necessary to decide all questions regarding the RFC process at
> once. Voting threshold is a very self-contained issue and we can decide it
> separately from other controversial changes.


Well, I think there are several issues here.

One - while the passing threshold is probably one of the most painful
issues with the current Voting RFC, it's hardly the only one.  Given it's
taken us many years to start tackling this, I think it's safe to say that
as a rule, we lack the motivation to tackle these issues.  I think it's
pretty clear that if we solve the threshold issue independently, it would
likely be years before we tackle the other issues, if ever.

Secondly - the threshold and voting eligibility are not, in any way,
independent.  They're two fundamental aspects of the same topic - how votes
take place.  A 2/3 majority out of a subset of ~200-300 people is very
different from a 2/3 majority out of a potential group of several thousand
people

Thirdly - implementation issues - that the original Voting RFC did NOT
intend to cover, later became covered by it by virtue of assumption.  I
think that implementation issues (implementing the same functionality that
we have right now in a better way) should not be subject to a vote, and
moving the threshold to 2/3 makes the current situation even worse than it
currently is, and should be for the most part up to the maintainers of the
code.

So no, I don't think we can simply 'abolish narrow margins' without
thinking about the implications as well as tackling the other shortcomings
of the 2011 Voting RFC.  With due respect, it reminds me of the hasty
approach we took back then, and that wasn't good.

Unless I'm missing something, we're currently in absolutely no hurry - we
just released 7.3, we can spend as much time as needed (to a reason) on
hashing out updated voting rules.  I'm speaking on behalf of myself, and
maybe Dmitry thinks differently - but I'm certainly fine waiting with that
RFC for several weeks or even a couple of months if needed.

Zeev

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins  wrote:

> Afternoon Zeev,
>
> I'm going to use unambiguous and direct language to make sure my intentions
> and concerns are communicated clearly, you can either receive this as a
> personal attack, or as a contributor being direct, I would prefer the
> latter.
>

I fail to see how in the way it was written it could not be taken as a
personal attack, but since you wrote it, I'll happily take your
interpretation of it.  No hard feelings.


> You pushed FFI into php-src on a simple majority


I didn't push FFI.  Yes, it was my idea to invest in it a year or two ago,
but Dmitry took it from A to Z.  Contrary to popular belief, we're not the
same person, nor do we have a hive mind...


> was
> incomplete (with leaks),


I would say that Dmitry has by far the best track record of fixing any
outstanding issues - not only with his code, but with the code of mostly
everyone else contributing to PHP, so if there's one contributor where this
isn't something to worry about - that's him.


> and had zero justification for being included in
> php-src - it didn't require any internal API's and can function just fine
> as a PECL extension


Functionality isn't everything.  Very few extensions have a technical
requirement to be bundled - it's much more of a question of promotion.


> still you pushed through with the RFC and it was
> accepted on a simple majority.
>

I did not push this RFC in any way, nor did I even try to ask others to
vote for it (which I would have if I was 'pushing' it).  I actually agree
with you that the fact it didn't clear a 2/3 vote, and with a hefty margin
- is not very ideal.

You are now trying to push JIT into php-src on the same slim, clearly
> unacceptable majority, and even if you change the majority requirements,
> what's worse is you want to include it in a minor version. Once again, this
> is an incomplete feature, failing to support the architectures we support
> and declaring them unimportant.


I categorically disagree that it is an incomplete feature;  I presume
you're saying this because it currently supports Linux x86/x64?  Does that
make our mod_php feature incomplete because it doesn't support Windows?  Is
Swoole incomplete because it only supports Linux and Mac?  It's not unusual
for complicated pieces of software to first be available for specific
subsets of platforms, and than gradually be ported to others.  It may not
be the intention, but it's difficult not to take calling it "incomplete" as
something other than disparaging the mind-boggling levels of effort that
went into it over the last 7 years.  Seriously, it's akin to someone
handing us a goose that lays golden eggs, for free, and us complaining that
they require these special weeds to feed on.

You are pushing PHP towards a future where
> there is effectively a single contributor, possibly two, able to make
> changes to Zend+Opcache; You are changing core parts of PHP too fast and
> making other contributors, including the maintainers of external tooling
> which the ecosystem requires to function, uncomfortable.
>

These are valid concerns, which is why they are fact covered in the RFC.
Of course, it would be possible to make changes to the engine/OPcache
without maintaining JIT - which would in turn break only JIT, in case we
reach a situation where JIT has no maintainers, or they're unable to keep
up with the changes.  The architecture is purposely designed in a way that
the engine remains independent of the JIT layer.

I really don't think you have bad intentions, but think our processes are
> allowing us to make questionable decisions for the whole project, and this
> I intend to resolve, regardless of your next actions, before any more
> questionable decisions can be taken.


I think there were questionable decisions that happened long before
FFI/JIT, and still, it didn't cross my mind to suddenly change the rules
for them specifically.

I'm fine with waiting with the JIT vote until we figure out voting.  I
don't think we're in any rush as far as the decision is concerned (and we
can start discussing anyway).  I'm not fine with rushing to hastily change
the rules (while breaking the existing ones) to counter a specific RFC.

Zeev

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Nikita Popov]

On Thu, Jan 31, 2019 at 2:07 PM Zeev Suraski  wrote:

> >-Original Message-
> >From: Joe Watkins 
> >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

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon Zeev,

I'm going to use unambiguous and direct language to make sure my intentions
and concerns are communicated clearly, you can either receive this as a
personal attack, or as a contributor being direct, I would prefer the
latter.

Let us be clear about the things you are doing:

You pushed FFI into php-src on a simple majority, it had one user, was
incomplete (with leaks), and had zero justification for being included in
php-src - it didn't require any internal API's and can function just fine
as a PECL extension, still you pushed through with the RFC and it was
accepted on a simple majority.

You are now trying to push JIT into php-src on the same slim, clearly
unacceptable majority, and even if you change the majority requirements,
what's worse is you want to include it in a minor version. Once again, this
is an incomplete feature, failing to support the architectures we support
and declaring them unimportant. You are pushing PHP towards a future where
there is effectively a single contributor, possibly two, able to make
changes to Zend+Opcache; You are changing core parts of PHP too fast and
making other contributors, including the maintainers of external tooling
which the ecosystem requires to function, uncomfortable.

I really don't think you have bad intentions, but think our processes are
allowing us to make questionable decisions for the whole project, and this
I intend to resolve, regardless of your next actions, before any more
questionable decisions can be taken.

Cheers
Joe






On Thu, 31 Jan 2019 at 14:38, Zeev Suraski  wrote:

> 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 
> *Sent:* Thursday, January 31, 2019 3:26 PM
> *To:* Zeev Suraski 
> *Cc:* internals@lists.php.net
> *Subject:* Re: [PHP-DEV] RFC Abolish Narrow Margins
>
>
>
> Afternoon Zeev,
>
>
>
> I imagine you will not like what I have to say either: In light of the
> recent actions you have taken and are taking to push incomplete software
> into php-src on narrow margins, prematurely, it makes perfect sense to
> discuss margins independently, and I intend to do so. Your opinion will be
> taken into consideration when you cast your vote.
>
>
>
> I do insist, and will not be waiting two weeks, unless you agree to delay
> the JIT RFC until this issue is resolved.
>
>
>
> Cheers
>
> Joe
>
>
>
>
>
>
>
> On Thu, 31 Jan 2019 at 14:07, Zeev Suraski  wrote:
>
> >-Original Message-
> >From: Joe Watkins 
> >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
>
>

RE: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

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 
Sent: Thursday, January 31, 2019 3:26 PM
To: Zeev Suraski 
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins

Afternoon Zeev,

I imagine you will not like what I have to say either: In light of the recent 
actions you have taken and are taking to push incomplete software into php-src 
on narrow margins, prematurely, it makes perfect sense to discuss margins 
independently, and I intend to do so. Your opinion will be taken into 
consideration when you cast your vote.

I do insist, and will not be waiting two weeks, unless you agree to delay the 
JIT RFC until this issue is resolved.

Cheers
Joe



On Thu, 31 Jan 2019 at 14:07, Zeev Suraski 
mailto:z...@zend.com>> wrote:
>-Original Message-
>From: Joe Watkins mailto:krak...@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

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Joe Watkins]

Afternoon Zeev,

I imagine you will not like what I have to say either: In light of the
recent actions you have taken and are taking to push incomplete software
into php-src on narrow margins, prematurely, it makes perfect sense to
discuss margins independently, and I intend to do so. Your opinion will be
taken into consideration when you cast your vote.

I do insist, and will not be waiting two weeks, unless you agree to delay
the JIT RFC until this issue is resolved.

Cheers
Joe



On Thu, 31 Jan 2019 at 14:07, Zeev Suraski  wrote:

> >-Original Message-
> >From: Joe Watkins 
> >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
>
>

RE: [PHP-DEV] RFC Abolish Narrow Margins

[Zeev Suraski]

>-Original Message-
>From: Joe Watkins  
>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

Re: [PHP-DEV] [RFC] abolish narrow margins

[Stanislav Malyshev]

Hi!

> Things which don't effect the language, but are more of a question of
> preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for
> that matter, deciding about a different release cadence.  It's one thing to

That's one of the places where 50% or plurality vote would be
appropriate - when we have binary (or n-ary) choice for some decision
that has to be taken. We don't want to end up in an absurd situation of
not choosing any name or any release date because none of the options
has 2/3. So in this situation, I think we go with the majority or
plurality (in case of multiple options) vote.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Christoph M. Becker]

On 12.07.2018 at 10:10, Zeev Suraski wrote:

> I think the problem is that there are cases where a 2/3 vote (or a vote at
> all) doesn't make sense.  True, we didn't have too many of those in the
> past - but as we reform, I think it's important to take note of them.
> Things which don't effect the language, but are more of a question of
> preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for
> that matter, deciding about a different release cadence.  It's one thing to
> add a language construct, to change the behavior of a function or to
> add/remove an extension - this bubbles into people's code and we'd have to
> live with this decision and its implications even in a decade's time -
> while we can change our release cadence 3 times in between (if we wanted
> to), and obviously whether phpng ended up being called PHP 6 or PHP 7 had
> no technical meaning, only a 'marketing' one.  Then there are also
> implementation decisions - where things in the past have been a bit unclear
> - and I think it's needed to clarify that such decisions (including
> substantial refactoring, as long as there's no negative end-user impact)
> should not require voting, but are up for the folks actually maintaining
> that particular piece of code to decide.
> So while I think non 2/3 votes would be uncommon, I do think we need to
> have provisions for them - and voting to make everything 2/3 right now
> without discussing the wider scope is wrong IMHO.

Perhaps the most important factor is whether we actually *change*
something (e.g. new feature, deprecation, voting process), or whether we
merely have to make a decision about something that is not covered by
existing rules (e.g. next version 7.4 or 8).  Of course, that's still
somewhat vague, but might be a good rule of thumb.

> Here's one example of our lacking rules (IMHO of course) - this has been in
> the attic for just under a year, and now we're considering to just move it
> to a vote within days.  I don't think that should be possible :)  The way I
> see it, the voting period has to happen immediately after the mandatory
> discussion period - and in a very predictable manner .  If an RFC goes
> dormant, there should be a new discussion period prior to voting.

ACK.  In my opinion, we would profit from a more structured and
automated RFC solution.  As it is now, the administration of the RFCs
need too much manual intervention.  For instance, marking an obviously
inactive RFC as such, requires to manually edit the RFC overview, *and*
to modify the status on the actual RFC.  Also it would be benefitial, if
votes closed automatically on the scheduled end date.  Or regarding this
very case: if there are no further replies to the RFC discussion thread
for a week or so, the RFC should automatically moved to “inactive”, if
it hasn't been moved to voting in the meantime.

-- 
Christoph M. Becker

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Zeev Suraski]

On Thu, Jul 12, 2018 at 7:38 AM Joe Watkins  wrote:

> Zeev,
>
> > I think our voting rules are in need of a much thorough review than just
> pushing the limit to 2/3 - which also IMHO doesn't tackle the difference
> scenarios that exist out there.
>
> Agree, they need reform, but rather than trying to discuss and pass a
> monolithic RFC that tries to solve all problems, I chose (a year ago) to
> start here; Simply raising the bar simplifies the rules we currently have
> and so simplifies their reform (in detail and process).
>

I think the problem is that there are cases where a 2/3 vote (or a vote at
all) doesn't make sense.  True, we didn't have too many of those in the
past - but as we reform, I think it's important to take note of them.
Things which don't effect the language, but are more of a question of
preference - e.g., the decision to name phpng as PHP 6 vs PHP 7 - or for
that matter, deciding about a different release cadence.  It's one thing to
add a language construct, to change the behavior of a function or to
add/remove an extension - this bubbles into people's code and we'd have to
live with this decision and its implications even in a decade's time -
while we can change our release cadence 3 times in between (if we wanted
to), and obviously whether phpng ended up being called PHP 6 or PHP 7 had
no technical meaning, only a 'marketing' one.  Then there are also
implementation decisions - where things in the past have been a bit unclear
- and I think it's needed to clarify that such decisions (including
substantial refactoring, as long as there's no negative end-user impact)
should not require voting, but are up for the folks actually maintaining
that particular piece of code to decide.
So while I think non 2/3 votes would be uncommon, I do think we need to
have provisions for them - and voting to make everything 2/3 right now
without discussing the wider scope is wrong IMHO.

Also while generally I very much agree with the 'agile' sentiment of fixing
things gradually instead of in one monolithic step - our voting rules are
so lacking that it feels like putting a band aid on a gunshot wound...
By the way, I still think there's a lot of work that still needs to happen
on my proposal - perhaps factor in quorums, how votes relate to deadlines -
we can probably learn quite a bit from our experience including in recent
weeks - but I think it's mature enough for others to comment on it, and I
would be very happy for others to join me in drafting it.

I'm not following your logic for further delaying voting on this RFC, in
> fact I don't see any logic, just an assertion ;)


Here's one example of our lacking rules (IMHO of course) - this has been in
the attic for just under a year, and now we're considering to just move it
to a vote within days.  I don't think that should be possible :)  The way I
see it, the voting period has to happen immediately after the mandatory
discussion period - and in a very predictable manner .  If an RFC goes
dormant, there should be a new discussion period prior to voting.

On my logic for not dealing with it right now, it's twofold:
1. There's too much activity going on around last minute 7.3 RFCs for many
people to have the bandwidth to discuss it in a serious manner.
2. It seems wrong to change the rules mid-flight in a way which might
affect the current 7.3 votes which are already under way (not that I think
it will affect most of them - but it still seems wrong).

Sorry for not actually mentioning that previously :)

Zeev

Re: [PHP-DEV] [RFC] abolish narrow margins

[Joe Watkins]

Zeev,

> I think our voting rules are in need of a much thorough review than just
pushing the limit to 2/3 - which also IMHO doesn't tackle the difference
scenarios that exist out there.

Agree, they need reform, but rather than trying to discuss and pass a
monolithic RFC that tries to solve all problems, I chose (a year ago) to
start here; Simply raising the bar simplifies the rules we currently have
and so simplifies their reform (in detail and process).

I'm not following your logic for further delaying voting on this RFC, in
fact I don't see any logic, just an assertion ;)

Cheers
Joe

On Thu, Jul 12, 2018 at 2:22 AM, Sara Golemon  wrote:

> On Wed, Jul 11, 2018 at 7:10 PM, Andrea Faulds  wrote:
> > 2/3+1 is silly, though. 2/3 already means there's twice as many agreeing
> as
> > disagreeing, having +1 doesn't serve the tie-breaking function there
> that it
> > does for 50%+1. But that was indeed a knife-edge RFC, it was actually
> saved
> > by someone chosing to vote Yes at the last minute.
> >
> I can buy that argument, but since there IS room to disagree, then
> such should be spelled out clearly in the voting update RFC.  Let's
> decide and not leave it to subjective interpretation.
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] abolish narrow margins

[Sara Golemon]

On Wed, Jul 11, 2018 at 7:10 PM, Andrea Faulds  wrote:
> 2/3+1 is silly, though. 2/3 already means there's twice as many agreeing as
> disagreeing, having +1 doesn't serve the tie-breaking function there that it
> does for 50%+1. But that was indeed a knife-edge RFC, it was actually saved
> by someone chosing to vote Yes at the last minute.
>
I can buy that argument, but since there IS room to disagree, then
such should be spelled out clearly in the voting update RFC.  Let's
decide and not leave it to subjective interpretation.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Andrea Faulds]

Hey Sara,

Sara Golemon wrote:


I don't remember the specifics about integer semantics (which fell
precisely on 2/3 and thus would have failed the +1 check), but again
I'll offer than perhaps both needed more discussion, and maybe
shouldn't have passed.  *shrug*

-Sara



2/3+1 is silly, though. 2/3 already means there's twice as many agreeing 
as disagreeing, having +1 doesn't serve the tie-breaking function there 
that it does for 50%+1. But that was indeed a knife-edge RFC, it was 
actually saved by someone chosing to vote Yes at the last minute.


--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Stanislav Malyshev]

Hi!

> See 
> and particularly .

Ah yes, thanks, I thought I remembered something like that. It's a bit
old but still good. Looks like the number of RFCs that would suffer from
move to 2/3 is very low, thus I think it's a good idea.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Sara Golemon]

On Wed, Jul 11, 2018 at 5:12 PM, Christoph M. Becker  wrote:
> and particularly .
>
Interesting, better than I'd thought actually.
It's odd that the 64bit stuff was the one that was < 2/3rds.  iirc the
only honestly contentious thing about that was the potential to break
existing extensions (which php-ng pretty did anyway).  I know there
was concern about those two having to merge, and I know I fell on the
side of the one that was developed more publicly, but it still seems
like a no-brainer to me.

I don't remember the specifics about integer semantics (which fell
precisely on 2/3 and thus would have failed the +1 check), but again
I'll offer than perhaps both needed more discussion, and maybe
shouldn't have passed.  *shrug*

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Christoph M. Becker]

Am 11.07.2018 um 20:18 schrieb Stanislav Malyshev:

> That said, I'd love to see how many of the accepted RFCs we have now
> were actually accepted by margin between 50%+1 and 2/3 and what they
> are, if the number is very low maybe it's irrelevant. Unfortunately I
> don't have time to do it myself soon, but it would be super-awesome if
> somebody did.

See 
and particularly .

-- 
Christoph M. Becker



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] abolish narrow margins

[Zeev Suraski]

> -Original Message-
> From: Joe Watkins [mailto:krak...@php.net]
> Sent: Wednesday, July 11, 2018 7:41 PM
> To: PHP internals 
> Subject: [PHP-DEV] [RFC] abolish narrow margins
> 
> Afternoon internals,
> 
> I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote in 
> the
> very near future ...
> 
> We discussed it a year ago, and discussion died down to nothing (possibly
> because it was sidetracked); If there are no objections I'll bring it to vote 
> in the
> coming days ...


Last year I worked on a bigger rework of our voting rules that tackles this, 
among other topics - given the many deficiencies of the original Voting RFC 
(which was hastily drafted, approved with virtually zero discussion, and yet 
has been considered as some sort of constitution ever since).  I admit I didn't 
have the mental strength to bring it up for discussion but I think our voting 
rules are in need of a much thorough review than just pushing the limit to 2/3 
- which also IMHO doesn't tackle the difference scenarios that exist out there.

I think it would make sense to start discussing that (as well as the 
abolish-narrow-margins RFC along with it if you prefer to put it to a vote) as 
soon as we're done with the 7.3 contents, and in preparation for 7.4/8.0 (i.e. 
around the September/October timeframe).  We could of course start discussing 
it sooner, but at least I don't think it makes sense to vote on either of these 
right now.

Zeev


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Paul Jones]

> On Jul 11, 2018, at 12:10, Sara Golemon  wrote:
> 
> On Wed, Jul 11, 2018 at 12:41 PM, Joe Watkins  wrote:
>> I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote
>> in the very near future ...
>> 
>> We discussed it a year ago, and discussion died down to nothing (possibly
>> because it was sidetracked); If there are no objections I'll bring it to
>> vote in the coming days ...

Since you brought it up ...

> "The current political climate of Earth

It's probably less "Earth" and more "Western civilization."

> votes that are won by narrow margins build resentment among voters

Well, certainly among some. I have to wonder if this is a reference to the 
author's favored political outcomes being thwarted.

> can lead to instability in the ecosphere

The "ecosphere" of Earth? That's an interesting assertion. I wonder if it's 
true.

> and could be considered harmful to democracy.

There's a long list of things that "could be considered harmful to democracy."

In any case, are we turning this list into a political forum? Because I for one 
can do without it here. I find it in plenty of other places.

I don't have any more to say on that aspect of this topic right now, unless and 
until someone else here sees fit to continue it -- in which case, I'll be happy 
to respond.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php





-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Levi Morrison]

On Wed, Jul 11, 2018 at 12:19 PM Stanislav Malyshev  wrote:
>
> Hi!
>
> > We discussed it a year ago, and discussion died down to nothing (possibly
> > because it was sidetracked); If there are no objections I'll bring it to
> > vote in the coming days ...
>
> I tend to agree with the sentiment, but not 100%. I think there are two
> kinds of changes - one kind is more fundamental than the other. I.e., if
> we add a major feature to the language (like strict type checks, for
> example) it is going to have major influence on the language and
> virtually everybody using it. You can't just ignore it. This also goes
> to changes which alter ways that the syntax works, etc. which have
> potential to break existing code (even if it's bad code, still).
>
> Then there are more "neutral" changes - like adding an utility function
> or an option to a function. PHP has a lot of "syntax sugar" functions
> and sometimes even "kitchen sink" functions - ones that most people
> don't use but some do. Having one more would not be that big of a deal -
> that's where, unlike the above, "what you don't use doesn't hurt you" is
> true.
>
> You probably have guessed already what I am getting at - the second kind
> is probably OK to have 50%+1, since people that don't need this
> option/function can vote no but still we can have it if more people do.
> The counter-argument could be that people that don't need it can just
> avoid voting, but then we don't have clear boundary between "I don't
> think it's useful for enough people to add it" and "I am on vacation and
> haven't bothered to even have an opinion".

If it's a utility function and somehow ~49% of voters oppose it...
think about that. It's 49% objectionable! I don't think that should
pass, not even for a utility function people.

> That said, I'd love to see how many of the accepted RFCs we have now
> were actually accepted by margin between 50%+1 and 2/3 and what they
> are, if the number is very low maybe it's irrelevant. Unfortunately I
> don't have time to do it myself soon, but it would be super-awesome if
> somebody did.

I did this analysis in the past. There are very few RFCs that passed
in this window between 50%+1 and 2/3, but there are a few. The
array_key_first/last RFC is on track to pass in this region.

> P.S. The question of quorum is interesting to explore, though I am not
> sure how we figure out the numbers.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Stanislav Malyshev]

Hi!

> We discussed it a year ago, and discussion died down to nothing (possibly
> because it was sidetracked); If there are no objections I'll bring it to
> vote in the coming days ...

I tend to agree with the sentiment, but not 100%. I think there are two
kinds of changes - one kind is more fundamental than the other. I.e., if
we add a major feature to the language (like strict type checks, for
example) it is going to have major influence on the language and
virtually everybody using it. You can't just ignore it. This also goes
to changes which alter ways that the syntax works, etc. which have
potential to break existing code (even if it's bad code, still).

Then there are more "neutral" changes - like adding an utility function
or an option to a function. PHP has a lot of "syntax sugar" functions
and sometimes even "kitchen sink" functions - ones that most people
don't use but some do. Having one more would not be that big of a deal -
that's where, unlike the above, "what you don't use doesn't hurt you" is
true.

You probably have guessed already what I am getting at - the second kind
is probably OK to have 50%+1, since people that don't need this
option/function can vote no but still we can have it if more people do.
The counter-argument could be that people that don't need it can just
avoid voting, but then we don't have clear boundary between "I don't
think it's useful for enough people to add it" and "I am on vacation and
haven't bothered to even have an opinion".

That said, I'd love to see how many of the accepted RFCs we have now
were actually accepted by margin between 50%+1 and 2/3 and what they
are, if the number is very low maybe it's irrelevant. Unfortunately I
don't have time to do it myself soon, but it would be super-awesome if
somebody did.

P.S. The question of quorum is interesting to explore, though I am not
sure how we figure out the numbers.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] abolish narrow margins

[Sara Golemon]

On Wed, Jul 11, 2018 at 12:41 PM, Joe Watkins  wrote:
> I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote
> in the very near future ...
>
> We discussed it a year ago, and discussion died down to nothing (possibly
> because it was sidetracked); If there are no objections I'll bring it to
> vote in the coming days ...
>
"The current political climate of Earth shows us that votes that are
won by narrow margins build resentment among voters, can lead to
instability in the ecosphere, and could be considered harmful to
democracy."

Snicker... I want to vote for this purely to make that sentence part
of our bylaws.

In all seriousness though, I'm in favor of this.  66.666% isn't an
unreasonable bar.  If you can't get 2 out of 3 people to think your
idea makes sense, then it might need work.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php