On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot <peterko...@gmail.com> wrote:
> Hello. > > On Wed, 7 Aug 2019 at 18:56, Chase Peeler <chasepee...@gmail.com> wrote: > > > > > > > > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot <peterko...@gmail.com> > wrote: > >> > >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski <z...@php.net> wrote: > >> > > >> > > >> > > >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd <dan...@basereality.com> > wrote: > >> >> > >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot <peterko...@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 > > chasepee...@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 chasepee...@gmail.com
