Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106418
MIME-Version: 1.0
References: <CAFPFaML19B_RehrUQLEy_oFae-H5r3+BpUGg=GF1js83cJpJqQ@mail.gmail.com>
 <CAPKYkKxHkQojFnCs09htRFvTrV_SReQV7YVo6RxRSmuN9H_Q0w@mail.gmail.com>
 <CALKiJKrXatW9Va0bjsUQD+TCCge=HcMzyV8Uf+rq+_s9xoyyuQ@mail.gmail.com>
 <CAFPFaMJKq7rqY0ZSPuimWVTY8ZZc=jXJS3__fNRnvBfp+W3PXg@mail.gmail.com>
 <CAPhkiZy-5Z0CLMUCZ_0OKaUrONrbVfZztfvRcOMUvjEFRp9Xqg@mail.gmail.com>
 <CAAfnsFU_ROGbfPqo33xgVH=nZ_6D7bS_4NkC8YXnOF45_82Z6A@mail.gmail.com>
 <CA+kxMuTa5DDee9Hu5d5DHxndpkNcu25g7qUAcvAf1x0ajN9dfA@mail.gmail.com>
 <CAJHtznxeouocXqgeHE9CriaxE+wxe0vsiRWMNnuHZadqipcN7w@mail.gmail.com>
 <CAAfnsFU-zF73SWsboGRf+Hua8emrcw_SVTLsnK_WOzZyxMKCJQ@mail.gmail.com>
 <CAPKYkKyH0FKaVdRVQujVv_H=FKG+H_qx9O5bxNEFKbymHr0cSQ@mail.gmail.com> <CAAfnsFU3Onb_wzSv+9q1rYk=oo+DLB6N0PpcJOUhVpgWVOgajA@mail.gmail.com>
In-Reply-To: <CAAfnsFU3Onb_wzSv+9q1rYk=oo+DLB6N0PpcJOUhVpgWVOgajA@mail.gmail.com>
Date: Wed, 7 Aug 2019 13:03:32 -0400
Message-ID: <CAPKYkKyFcgt+7W2e=izP3_E218KewRUfN8e8c1J-ovS6CEpyhQ@mail.gmail.com>
To: Peter Kokot <peterkokot@gmail.com>
Cc: Zeev Suraski <zeev@php.net>, Dan Ackroyd <Danack@basereality.com>, 
	Andrey Andreev <narf@devilix.net>, "G. P. B." <george.banyard@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000728900058f89ecdd"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000728900058f89ecdd
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot <peterkokot@gmail.com> wrote:

> Hello.
>
> On Wed, 7 Aug 2019 at 18:56, Chase Peeler <chasepeeler@gmail.com> wrote:
> >
> >
> >
> > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot <peterkokot@gmail.com>
> wrote:
> >>
> >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <zeev@php.net> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <Danack@basereality.com>
> wrote:
> >> >>
> >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterkokot@gmail.com>
> wrote:
> >> >> >
> >> >> > Yes, last time I was asking this, there was a clarification that
> >> >> > certain people from the group internals can veto particular RFC.
> >> >>
> >> >> Please could you point to where this alleged rule has ever been
> >> >> written down or agreed to?
> >> >
> >> >
> >> > There's indeed no such rule that any individuals have a veto power.
> >> >
> >> >>
> >> >> Although certain people may have claimed this is a rule, it's never
> >> >> been agreed afaik.
> >> >
> >> >
> >> > I'm not aware of anybody who ever claimed that such a rule existed,
> either.  If people are alluding to me - then I don't claim I can veto
> anything;  I think it's also clear from what I think about the short tags
> deprecation RFC that if I had veto power, that would be an instance where
> I'd use it.  The reason we went for V2 aren't because of a veto, but
> because of issues in the previous RFC.
> >> >
> >> > With that said - the source code of PHP is copyrighted by the PHP
> Group - and it's a fact that is mentioned at the top of every PHP source
> file.  The PHP Group is mostly inactive, and will likely stay this way, but
> under some extreme situations - it might choose to act (if ever - probably
> primarily around things that have to do with process).
> >> >
> >> >> I think when we adopt a Code of Conduct one of the things we need to
> >> >> make explicit is that "claiming authority that is not codified" is
> >> >> explicitly a thing that will not be allowed in internals discussions
> >> >> as it seems to keep happening and results in a lot of confusion, and
> >> >> frustration.
> >> >
> >> >
> >> > The more accurate word here is 'if', rather than 'when'. But I don't
> think there's a need to wait for a CoC on this one - it should be clear
> that no individual has veto powers, but it should be also clear that not
> everything is up for a vote.
> >> >
> >> > Zeev
> >> >
> >>
> >> Veto has been mentioned here
> >> https://externals.io/message/105201#105558
> >>
> >> I'm not having any issues with veto being used here or not on a
> >> previous RFC from people that are in the internals since day 1. I
> >> think we should respect that they have issues with proposals coming up
> >> in recent years, but hopefully group will also understand us - users
> >> and new contributors a bit that we just want to have a bit of cleanup
> >> of legacy things here and there :)
> >>
> >> Thanks and have a nice day.
> >> --
> >> Peter Kokot
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> > What powers are available, and to whom they are available, is probably
> something that should be moved to another thread. We currently have at
> least three different discussions going on in this thread:
> > 1.) The RFC itself
> > 2.) Default handling of the ini setting
> > 3.) Whether certain people can veto RFCs.
> >
> > To address Andrey's initial concern, which is currently leading to him
> not voting:
> >
> > Nobody is vetoing anything. Due to both the procedural issues (the way
> the voting was structured with two options) as well as the severity of the
> issues raised after the voting, another RFC was proposed that supersedes
> the original RFC. The procedural issues alone were enough to warrant
> another vote on an RFC that had fixed those issues. This means that, for
> all intents and purposes, the first RFC never existed. If the current RFC
> passes, then it will be implemented as proposed. If it fails, then
> treatment of short tags will remain as it currently is.
> >
> > I hope you will reconsider your decision to not vote on this new RFC. I
> understand your concerns. As someone that didn't like the outcome of the
> first vote either, I also didn't feel that a revote just because a lot of
> people decided to speak up after the fact was the correct course of action.
> I don't think that is what is happening here, though.
> >
> > --
> > Chase Peeler
> > chasepeeler@gmail.com
>
> Just to be more clear here. If the RFC fails then the short opening
> tags will stay in PHP for ever. I'm not sure what will change in 5 or
> 10 years so much so considering the feedback I think we should then
> leave them in for ever and enable them by default everywhere and have
> two PHP opening tags. Yes, this is what happens when there is no plan
> from key people involved here.
>
> And why is supporting two types of opening tags so bad that it justifies
such a large BC break? Support for short tags has existed since PHP3. Can
you point to anything you've written or used that would have been better
had short tags never existed?


> --
> Peter Kokot
>


-- 
Chase Peeler
chasepeeler@gmail.com

--000000000000728900058f89ecdd--