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

Reply via email to