All,
https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
from our guidelines of deprecating features first, and removing them
later; It’s addressed in the RFC – but I’m a bit worried that this opens
the door to jumping from any sort of notice/warning into errors or removed
features without any deprecation phase.
In comparison, in Nikita’s RFC for removing E_STRICT – there aren’t any
proposed ‘jumps’ to E_RECOVERABLE_ERROR that don’t first go through
E_DEPRECATED.
Should we not go through this deprecation cycle, even if may feel anxious
to get rid of this behavior?
Zeev
Le lun. 2 mars 2015 à 15:24, Zeev Suraski zeev@zend.com a écrit :
All,
https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
from our guidelines of deprecating features first, and removing them
later; It’s addressed in the RFC – but I’m a bit worried that this opens
the door to jumping from any sort of notice/warning into errors or removed
features without any deprecation phase.In comparison, in Nikita’s RFC for removing
E_STRICT– there aren’t any
proposed ‘jumps’ toE_RECOVERABLE_ERRORthat don’t first go through
E_DEPRECATED.Should we not go through this deprecation cycle, even if may feel anxious
to get rid of this behavior?
I'm all for deprecating before it gets removed (especially since I voted
"no" to that).
Patrick
On Mon, Mar 2, 2015 at 4:10 PM, Patrick ALLAERT patrickallaert@php.net
wrote:
Le lun. 2 mars 2015 à 15:24, Zeev Suraski zeev@zend.com a écrit :
All,
https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
from our guidelines of deprecating features first, and removing them
later; It’s addressed in the RFC – but I’m a bit worried that this opens
the door to jumping from any sort of notice/warning into errors or
removed
features without any deprecation phase.In comparison, in Nikita’s RFC for removing
E_STRICT– there aren’t any
proposed ‘jumps’ toE_RECOVERABLE_ERRORthat don’t first go through
E_DEPRECATED.Should we not go through this deprecation cycle, even if may feel anxious
to get rid of this behavior?I'm all for deprecating before it gets removed (especially since I voted
"no" to that).
Same to me, I voted no because we're gonna break something which is not
"that bad" and turn it to a clear breakage in one step.
I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0
and remove in 7.1 or 7.2 or whatever.
We chose not to have a 5.7 for deprecation purpose only (or not), but this
doesn't mean 7.0 shouldn't deprecate anything IMO.
Julien.Pauli
Same to me, I voted no because we're gonna break something which is not
"that bad" and turn it to a clear breakage in one step.
I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0
and remove in 7.1 or 7.2 or whatever.
We chose not to have a 5.7 for deprecation purpose only (or not), but this
doesn't mean 7.0 shouldn't deprecate anything IMO.
We should not remotely consider to remove things like that in 7.x, ever.
This will simply make applications migration to latest 7 series a nightmare.
And yes, I do consider it was a strategical mistake to have rejected 5.7
for this exact reason. Same for the random features freeze deadline, we end
up now with so many decisions to take on a hurry, while many of them are
critical for 7.
Both should be reconsidered. I do not think that will affect the final
release date for 7.
Hi all,
On Mon, Mar 2, 2015 at 4:10 PM, Patrick ALLAERT patrickallaert@php.net
wrote:Le lun. 2 mars 2015 à 15:24, Zeev Suraski zeev@zend.com a écrit :
All,
https://wiki.php.net/rfc/array-to-string (which I voted yes to)
deviates
from our guidelines of deprecating features first, and removing them
later; It’s addressed in the RFC – but I’m a bit worried that this
opens
the door to jumping from any sort of notice/warning into errors or
removed
features without any deprecation phase.In comparison, in Nikita’s RFC for removing
E_STRICT– there aren’t any
proposed ‘jumps’ toE_RECOVERABLE_ERRORthat don’t first go through
E_DEPRECATED.Should we not go through this deprecation cycle, even if may feel
anxious
to get rid of this behavior?I'm all for deprecating before it gets removed (especially since I voted
"no" to that).Same to me, I voted no because we're gonna break something which is not
"that bad" and turn it to a clear breakage in one step.
I would prefer we E_DEPRACTE before E_ERRORing , we can deprecate in 7.0
and remove in 7.1 or 7.2 or whatever.
We chose not to have a 5.7 for deprecation purpose only (or not), but this
doesn't mean 7.0 shouldn't deprecate anything IMO.
I had same idea, but I voted yes.
Conversion from array to string is a bug should be fixed anyway.
There may be code that checks invalid "Array" string, though.
I think changing E_NOTICE to E_DEPRECATED/E_STRICT is good idea.
E_DEPRECATED/E_STRICT then E_NOTICE/E_WARNING/E_ERROR
is better path. Users should be able to catch bugs with
E_DEPRECATED/E_STRICT
also.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
from our guidelines of deprecating features first, and removing them
later;Should we not go through this deprecation cycle, even if may feel anxious
to get rid of this behavior?
I don't think it's required.
The purpose of deprecation notices is to allow people to detect issues
in their code that is currently working as they want, and without
giving any warning messages. This allows them to estimate how much
effort it would be to upgrade to a newer version of PHP, one in which
the behaviour is no longer allowed, without actually having to
refactor all the code to find out.
In this case, the code already produces a notice that says the
behaviour is not completely ok, so people are able to detect where
array to string conversion is happening.
Having an intermediate step of E_DEPRECATED notice would not affect
the amount of code that they would need to change nor will it make it
significantly easier to detect places in their code where this
behaviour is occurring.
cheers
Dan
De : Zeev Suraski [mailto:zeev@zend.com]
https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
from our guidelines of deprecating features first, and removing them
later; It’s addressed in the RFC – but I’m a bit worried that this opens
the door to jumping from any sort of notice/warning into errors or removed
features without any deprecation phase.In comparison, in Nikita’s RFC for removing
E_STRICT– there aren’t any
proposed ‘jumps’ toE_RECOVERABLE_ERRORthat don’t first go through
E_DEPRECATED.Should we not go through this deprecation cycle, even if may feel anxious
to get rid of this behavior?
Sorry for the delay but I could not send emails during the last 3 weeks.
As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion. Array to string conversion will raise E_DEPRECATED in 7.0, and, then, fatal error in 7.1 or 7.2.
Please note that the switch from E_DEPRECATED to fatal error won't require any new RFC/discussion/vote as the fatal error is considered as approved. I just introduce an E_DEPRECATED phase for 7.0.
Regards
François
De : Zeev Suraski [mailto:zeev@zend.com]
https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
from our guidelines of deprecating features first, and removing them
later; It’s addressed in the RFC – but I’m a bit worried that this
opens
the door to jumping from any sort of notice/warning into errors or
removed
features without any deprecation phase.In comparison, in Nikita’s RFC for removing
E_STRICT– there aren’t any
proposed ‘jumps’ toE_RECOVERABLE_ERRORthat don’t first go through
E_DEPRECATED.Should we not go through this deprecation cycle, even if may feel
anxious
to get rid of this behavior?Sorry for the delay but I could not send emails during the last 3 weeks.
As you may have noticed if you had a look at the RFC or twitter, I have
decided to follow people's suggestion. Array to string conversion will
raiseE_DEPRECATEDin 7.0, and, then, fatal error in 7.1 or 7.2.
Hmm.. Sorry but no. I really do not think we can do this, this will bring a
major BC in 7.1+ and we do not allow BC but in extreme cases.
Please note that the switch from
E_DEPRECATEDto fatal error won't
require any new RFC/discussion/vote as the fatal error is considered as
approved. I just introduce anE_DEPRECATEDphase for 7.0.
Well, if it is, do it in 7.0. But changing that all of a sudden and making
it fatal in 7.1+ is an extremely bad idea :)
Regards
François
As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion.
Please note that the switch fromE_DEPRECATEDto fatal error won't require any new RFC/discussion/vote
as the fatal error is considered as approved. I just introduce anE_DEPRECATEDphase for 7.0.
What. The. Fuck.
You edited the RFC after the voting had closed? You are not allowed to
edit an RFC after the voting has occurred.
I don't think we have any rules in place to deal with this; I don't
think anyone anticipated that anyone would actually try to do this. We
obviously need an explicit rule for this, but that can wait until 7.0
is closer to shipping, and we can contemplate RFC rules at leisure.
For now, please revert the changes your made to the RFC after it had
been closed. And whoever has the power to remove karma, please take
the power to edit RFCs away from Francois once that has been done.
Array to string conversion will raise
E_DEPRECATEDin 7.0, and, then, fatal error in 7.1 or 7.2.
You are being dumb here as well. We try to avoid breaking code in
point releases. This BC break can only be done at a major version.
E_DEPRECATED is not a magic bullet - that makes all BC problems go
away. The reason why we voted on it for 7.0 is that it is a major
break, but one that is acceptable to be done at a major version. It
would not be acceptable to change the behaviour in a minor version.
cheers
Dan
You are being dumb here as well. We try to avoid breaking code in
point releases. This BC break can only be done at a major version.
Technically, we're not allowed to move from from a working feature into a removed one without a deprecation phase.
So why I agree with you it's a problem to just edit the RFC without getting a wide OK for it after a vote has concluded, what's much worse is that so many people voted Yes for an RFC that violated that principle, and not s single person was bothered to even reply to a query about it. Note that contrary to what you said, a vote would have been equally required regardless of whether we follow our deprecation process, or violate it for no good reason.
You're right we won't be able to move to remove it in 7.x - but it's exactly at the same level that we mustn't move to an error in 7.0.
Zeev
You are being dumb here as well. We try to avoid breaking code in
point releases. This BC break can only be done at a major version.Technically, we're not allowed to move from from a working feature into a removed one without a deprecation phase.
We have historically broke BC a lot without deprecation. I also know
of no such rule in our written RFCs. If historical behavior says
otherwise, and we don't have this written down anywhere... how can you
claim this is a rule?
You are being dumb here as well. We try to avoid breaking code in
point releases. This BC break can only be done at a major version.Technically, we're not allowed to move from from a working feature into a
removed one without a deprecation phase.
I don't think this is true. There is no requirement for us to deprecate
something before we remove it. Deprecation is a courtesy to our users in
cases where a heavily used feature is being dropped.
Realistically most people consider E_NOTICE to be a higher error level than
E_DEPRECATED. If somebody is willing to suppress the notices this currently
generates, chances are very high that deprecations are suppressed as well.
I don't see any release process issues with dropping this without
deprecation. (But I'm still -1 on the change, because I don't see why we'd
suddenly want to change this one relatively unimportant notice to be fatal
while leaving everything else alone.)
Nikita
You are being dumb here as well. We try to avoid breaking code in
point releases. This BC break can only be done at a major version.Technically, we're not allowed to move from from a working feature into a
removed one without a deprecation phase.I don't think this is true. There is no requirement for us to deprecate
something before we remove it. Deprecation is a courtesy to our users in
cases where a heavily used feature is being dropped.
I think we do not need to argue about the impact of having something
generating a fatal error all of a sudden in 7.1. Or am I missing
something? :)
Realistically most people consider
E_NOTICEto be a higher error level than
E_DEPRECATED. If somebody is willing to suppress the notices this currently
generates, chances are very high that deprecations are suppressed as well.
I don't see any release process issues with dropping this without
deprecation. (But I'm still -1 on the change, because I don't see why we'd
suddenly want to change this one relatively unimportant notice to be fatal
while leaving everything else alone.)
Same, if anything doing fatal then it has to be done in 7.0. Also I
have to agree with Zeev on that, a warning or deprecation notice
should be enough.
I know it is not what many users want, to clean up such things, but we
decided not to have a 5.7 to prepare such removals, let act
accordingly.
cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi Zeev,
Technically, we're not allowed to move from from a working feature into a removed one without a deprecation phase.
Please can you point me to where this is written down? Please also
show me where it says that this rule cannot be over-ridden by an RFC,
which is our path of changing rules.
The point of deprecating things is to smooth the path of fixing
issues. It allows people to detect in their codebase places where
there is code that is currently working fine without error, that is
going to break in a future version of PHP.
Any array to string conversion is already detectable as it emits a
'notice'. It does not need an intermediate step of changing the notice
to being a deprecation warning; that provides no benefit to users.
Rowan wrote:
you should pause, make a cup of tea, and redraft the e-mail.
That was the redrafted version.
The edits to the RFC were made two weeks ago. In Francois' defence he
himself alerted the list to the changes. But the unapproved editing
also meant that if there was someone else who was concerned about the
BC break, they might not have raised an RFC to revert the RFC, before
the cut off time for RFCs. This is one of the reasons why someone
editing the text of a passed RFC is utterly unacceptable.
cheers
Dan
Dan Ackroyd wrote on 19/03/2015 18:11:
Rowan wrote:
you should pause, make a cup of tea, and redraft the e-mail.
That was the redrafted version.
And yet it still accused another contributor of "being dumb", and
demanded they have access revoked. That is not a respectful or
proportional response to the situation.
The edits to the RFC were made two weeks ago. In Francois' defence he
himself alerted the list to the changes. But the unapproved editing
also meant that if there was someone else who was concerned about the
BC break, they might not have raised an RFC to revert the RFC, before
the cut off time for RFCs. This is one of the reasons why someone
editing the text of a passed RFC is utterly unacceptable.
Anyone knowledgeable enough about the process to raise such an RFC
would, at worst, have expressed confusion about the validity of the
edit. Note that the text of the vote remains "Yes to replace E_NOTICE
with E_RECOVERABLE_ERROR, No for no change." so it's kind of obvious
that's what was agreed to. There is no inline editing of the text to
make it look like this was always the case, and the wiki provides full
history to anyone who cares to check.
Again, I agree that editing the RFC was wrong here, but I think a
"please don't do this again" would have been sufficient.
Regards,
Rowan Collins
[IMSoP]
Dan Ackroyd wrote on 19/03/2015 17:40:
As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion.
Please note that the switch fromE_DEPRECATEDto fatal error won't require any new RFC/discussion/vote
as the fatal error is considered as approved. I just introduce anE_DEPRECATEDphase for 7.0.
What. The. Fuck.
I agree with the substance of what you wrote, but would like to appeal
for some civility and Assumption of Good Faith.
When you find yourself typing the word "fuck" on a public mailing list,
you should pause, make a cup of tea, and redraft the e-mail.
You edited the RFC after the voting had closed? You are not allowed to
edit an RFC after the voting has occurred.
Yes, this was not a good idea. The RFC as accepted was for a fatal
error; a change to E_DEPRECATED would require a new RFC, or at least a
supplementary vote.
I don't think we have any rules in place to deal with this; I don't
think anyone anticipated that anyone would actually try to do this. We
obviously need an explicit rule for this, but that can wait until 7.0
is closer to shipping, and we can contemplate RFC rules at leisure.For now, please revert the changes your made to the RFC after it had
been closed. And whoever has the power to remove karma, please take
the power to edit RFCs away from Francois once that has been done.
Let's keep this in perspective - no permanent harm has been done, anyone
can revert the page, and Francois can learn from the mistake. These two
paragraphs can be boiled down to "Can you or someone revert it please,
to reflect the text as accepted."
Array to string conversion will raise
E_DEPRECATEDin 7.0, and, then, fatal error in 7.1 or 7.2.
You are being dumb here as well.
This sentence is simply unnecessary.
We try to avoid breaking code in
point releases. This BC break can only be done at a major version.
E_DEPRECATEDis not a magic bullet - that makes all BC problems go
away. The reason why we voted on it for 7.0 is that it is a major
break, but one that is acceptable to be done at a major version. It
would not be acceptable to change the behaviour in a minor version.
This point is valid.
Regards,
Rowan Collins
[IMSoP]
As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion.
Please note that the switch fromE_DEPRECATEDto fatal error won't require any new RFC/discussion/vote
as the fatal error is considered as approved. I just introduce anE_DEPRECATEDphase for 7.0.You edited the RFC after the voting had closed? You are not allowed to
edit an RFC after the voting has occurred.
Agreed. I hereby change my vote from 'Yes' to 'No' in protest of this action.
For now, please revert the changes your made to the RFC after it had
been closed.
Please. If we need to change the schedule, let that be a separate RFC.
And whoever has the power to remove karma, please take
the power to edit RFCs away from Francois once that has been done.
Now that's a bit heavy-handed. Let's call this a slap on the wrist and move on.
-Sara
Hi!
As you may have noticed if you had a look at the RFC or twitter, I have decided to follow people's suggestion.
Please note that the switch fromE_DEPRECATEDto fatal error won't require any new RFC/discussion/vote
as the fatal error is considered as approved. I just introduce anE_DEPRECATEDphase for 7.0.What. The. Fuck.
Let's tone down here. While editing RFC anytime after the vote has
started without advanced notice is unacceptable and should not be done,
I don't think it's anything but a honest mistake. Of course, even more
unacceptable is to change it when voting results are in. But let's not
create more drama of it then necessary. Wikipedia has a rule that says
"assume good faith" (yes, I know in practice it is more complicated :) -
I think we could use more invocation of this rule here too.
It looks like the RFC author has not really decided what he wants to do.
If he doesn't want to support the RFC anymore, as voted, he can just
withdraw it and let somebody pick it up if willing (that's what happened
to <=> RFC and scalar typing RFC, so we have precedents). Or create a
new different one to supersede the old one. What not should be done of
course is editing voted RFC and using that as a base for changes.
--
Stas Malyshev
smalyshev@gmail.com
De : Dan Ackroyd [mailto:danack@basereality.com]
As you may have noticed if you had a look at the RFC or twitter, I have
decided to follow people's suggestion.
Please note that the switch fromE_DEPRECATEDto fatal error won't
require any new RFC/discussion/vote
as the fatal error is considered as approved. I just introduce an
E_DEPRECATEDphase for 7.0.What. The. Fuck.
You edited the RFC after the voting had closed? You are not allowed to
edit an RFC after the voting has occurred.I don't think we have any rules in place to deal with this; I don't
think anyone anticipated that anyone would actually try to do this. We
obviously need an explicit rule for this, but that can wait until 7.0
is closer to shipping, and we can contemplate RFC rules at leisure.For now, please revert the changes your made to the RFC after it had
been closed. And whoever has the power to remove karma, please take
the power to edit RFCs away from Francois once that has been done.Array to string conversion will raise
E_DEPRECATEDin 7.0, and, then, fatal
error in 7.1 or 7.2.You are being dumb here as well. We try to avoid breaking code in
point releases. This BC break can only be done at a major version.
OK. OK. I revert the RFC to its original version. It will raise E_RECOVERABLE_ERROR in 7.0.
Before you burn me alive, here's what happened : I was in Africa during the last 3 weeks, and didn't have any way to post to the list. I just had one hour of internet access during all this time and wanted to use it to close the vote, but I saw Zeev's and Julien's comments asking for a deprecate phase in 7.0, and thought that, if there was a rule, I had to respect it. I am not as dumb as you may think, I know BC breaks must be introduced in major versions, but the requests to do so were coming from people who are supposed to know the rules better than I. So, I added a line at the end of the RFC and sent a private message via twitter to Zeev asking him to forward the information to the list to discuss whether this change after vote was considered as acceptable or not. Unfortunately, I discovered his reply this morning saying he preferred me to do it when I would be back. That's why you discovered it today. So, I probably shouldn't have modified the RFC when I closed the vote, but there was a context.
So, as it is not clear whether there's a rule saying that everything must be deprecated before being removed, I will implement the RFC exactly as it was voted.
And let me apologize for the misunderstandings I have caused.
Regards
François
I thought introducing a temporary E_DEPRECATED phase would be acceptable to everyone and I would have asked the list but I could not send emails from where I was during the last 2 weeks. I just had web access during 1 hour, read Zeev's and Julien's comments, added one line in the RFC, and then sent a twitter message to Zeev asking him to forward the change to the list so that it could be judged acceptable or not. Unfortunately,
was in Africa during the last 2 weekssatisfy everyone but it seems it is not the case.
Now, what should I say when people who are supposed to know the process better than me ask to delay the BC break to 7.1 or 7.2 ?
cheers
Dan
May I also add that it is not the first time people raise concerns about RFCs when vote starts. On different occasions, it was clear that most had not read the RFC before the vote was announced. I even have two RFCs which were planned for 7.0 and won't be in because I had to stop the vote and restart a discussion. When we have short timelines, as for 7.0, it's a real problem because restarting a discussion easily adds one month to the approval process. Actually, I don't know if, in this case, I shouldn't reply that the discussion is over and that it's just too late to wake up.
Regards
François
May I also add that it is not the first time people raise concerns about RFCs when vote starts. On different occasions, it was clear that most had not read the RFC before the vote was announced. I even have two RFCs which were planned for 7.0 and won't be in because I had to stop the vote and restart a discussion. When we have short timelines, as for 7.0, it's a real problem because restarting a discussion easily adds one month to the approval process. Actually, I don't know if, in this case, I shouldn't reply that the discussion is over and that it's just too late to wake up.
The problem is not the RFC process but us accepting idealistic
timelnes. It is why I did not vote (for the ones that did not respect
the RFC process) or no for the ones I totally disagree with.
But this is off topic imho, we took these decisions now we have to
work with that.
In any case, one thing has to end, the playing with the rules.
Discussions must happen for at least two weeks before a RFC goes to
vote, mail must be sent to announce each phase. And last but not
least, editing a RFC during or after the votes in a way that it
changes what people votes for or against is not something I want to
see. We have to solve this issue. Learning by doing :)
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
2015.03.19. 18:40 ezt írta ("Dan Ackroyd" danack@basereality.com):
As you may have noticed if you had a look at the RFC or twitter, I have
decided to follow people's suggestion.
Please note that the switch fromE_DEPRECATEDto fatal error won't
require any new RFC/discussion/vote
as the fatal error is considered as approved. I just introduce an
E_DEPRECATEDphase for 7.0.What. The. Fuck.
You edited the RFC after the voting had closed? You are not allowed to
edit an RFC after the voting has occurred.I don't think we have any rules in place to deal with this; I don't
think anyone anticipated that anyone would actually try to do this. We
obviously need an explicit rule for this, but that can wait until 7.0
is closer to shipping, and we can contemplate RFC rules at leisure.For now, please revert the changes your made to the RFC after it had
been closed. And whoever has the power to remove karma, please take
the power to edit RFCs away from Francois once that has been done.Array to string conversion will raise
E_DEPRECATEDin 7.0, and, then,
fatal error in 7.1 or 7.2.You are being dumb here as well. We try to avoid breaking code in
point releases. This BC break can only be done at a major version.
E_DEPRECATEDis not a magic bullet - that makes all BC problems go
away. The reason why we voted on it for 7.0 is that it is a major
break, but one that is acceptable to be done at a major version. It
would not be acceptable to change the behaviour in a minor version.cheers
Dan
We have no reason to think that this wasn't just a honest mistake, so there
is no reason for any sactions.
Personally I agree, we either remove it in 7.0(without prior deprecation as
we voted no for 5.7) or deprecate it in 7.0 and remove in the next major
version.
Everything else is a PITA and against our release process rfc.