Hello,
[r106883] introduces a new global setting to whitelist deprecated functions: $wgDeprecationWhitelist. Its documentation is:
/** * Function name whitelist for wfDeprecated warnings. You will not be warned * for usage of deprecated functions in this list. This is mainly usefull * for extension developers unable to not use certain deprecated functions * due to backward compatinility reasons. * @since 1.19 * @var array */
I do not think we want such setting in core since it does not make sense. Developers can opt-in to get deprecation warnings shown, it is not to have them whitelisted later with yet another global. Either the extension need to be fixed or the core call should not be deprecated.
So, I have reverted the change with [r106946]. That was then opposed a "fuck you" argument and reverted ....
* I am not going to engage in a revision war. * I am not going to mark 'ok' a revision I feel is wrong.
So this mail is merely asking for people to please have a look at the feature, comment on it and reach a consensus about whether we should or should not keep this setting.
Thanks.
[r106883] Introduced wgDeprecationWhitelist https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106883 [r106946] My reversion https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106946
Hey,
That was then opposed a "fuck you" argument and reverted ....
This seems to be quoting me out of context. Here is my full comment to Hashars revert of mine:
------
Ok, apparently I need to explain this once more - sort of getting tired of it, this is why I send a flipping email to the list with my reasoning.
Scenario: some interface gets changed for a valid reason in 1.19. You are an extension developer with an extension that needs to be compatible with 1.17 to 1.19. Now you do not have the time to put in code to handle both versions, which might be a lot of work depending on the interface change. So you want to ignore this usage of this detracted interface for now, and fix it later on. However, you want to get a warning as soon as you use some other detracted interface.
To me this very much comes off as a "fuck you" to extension developers. ------
I do not think we want such setting in core since it does not make sense. Developers can opt-in to get deprecation warnings shown, it is not to have them whitelisted later with yet another global. Either the extension need to be fixed or the core call should not be deprecated.
You are suggesting this feature is useless. The scenario I used as an example proves it is for developers, that want to have an option between "warnings" and "no warnings". I introduced the setting because I _needed_ it, and anticipate it to be useful for other people that have $wgDeprecationReleaseLimit set to false.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Jeroen De Dauw jeroendedauw@gmail.com wrote:
hashar wrote:
That was then opposed a "fuck you" argument and reverted ....
This seems to be quoting me out of context. Here is my full comment to Hashars revert of mine:
Jeroen, I am sorry about the misquote. I should have quoted the full text.
I apologize :-\
Just my 2 cents:
I don't think we need this kind of deprecation-warning filter in core.
As far as I know deprecation warnings are never shown more than once for every method, so it isn't going to pollute or obfuscate the error output when you're working with the code.
And users/production wouldn't be seeing them anyway, right ?
And if you maintain compatibility with an older version of MediaWiki, you might also find it useful to raise $wgDeprecationReleaseLimit ocasionally to only if there's any usage of more problematic / longest deprecated methods, and lower it again when you want to see them all.
-Krinkle
On Wed, Jan 11, 2012 at 12:45 PM, Antoine Musso hashar+wmf@free.fr wrote:
I do not think we want such setting in core since it does not make sense. Developers can opt-in to get deprecation warnings shown, it is not to have them whitelisted later with yet another global. Either the extension need to be fixed or the core call should not be deprecated.
I tend to agree that this isn't terribly useful, but I'm not willing to revert war over it. If we're voting, count me in the -1 column I suppose.
-Chad
On Wed, Jan 11, 2012 at 10:44 AM, Chad innocentkiller@gmail.com wrote:
On Wed, Jan 11, 2012 at 12:45 PM, Antoine Musso hashar+wmf@free.fr wrote:
I do not think we want such setting in core since it does not make sense. Developers can opt-in to get deprecation warnings shown, it is not to
have
them whitelisted later with yet another global. Either the extension need to be fixed or the core call should not be deprecated.
I tend to agree that this isn't terribly useful, but I'm not willing to revert war over it.
I tend to take the same position. :)
-- brion
Hey,
I tend to agree that this isn't terribly useful, but I'm not willing to
revert
war over it. If we're voting, count me in the -1 column I suppose.
I tend to take the same position. :)
Did you read what I wrote? How is it not useful? Please provide REASONING, that proves my argument is invalid. If you cannot do this, you have no valid reason for shouting -1.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On Wed, Jan 11, 2012 at 1:53 PM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
I tend to agree that this isn't terribly useful, but I'm not willing to
revert
war over it. If we're voting, count me in the -1 column I suppose.
I tend to take the same position. :)
Did you read what I wrote? How is it not useful? Please provide REASONING, that proves my argument is invalid. If you cannot do this, you have no valid reason for shouting -1.
Yes, I read what you wrote, I just happen to disagree with you. Please don't demand I make a mathematical proof of the universe making sense.
-Chad
Hey,
However, it seems better to just delay the deprecation in core a cycle.
The policy of "half deprecating" things, by placing a detraction notice in the docs but not have a call to wfDeprecated is very flawed. Either you deprecated something or you don't. And if you do, you make sure people that want to be able to know they are using a deprecated function as soon as they do are able to. This is what makes it useful for extension developers.
So, for everyone with $wgDeperectionReleaseLimit set to false, ie everyone that gets all deprecation notices, it's very useful to have a way to ignore a certain deprecated interface they can not take care of for some reason, rather then being forced to turn off deprecation warnings for everything.
Either error log settings or $wgDevelopmentWarnings can handle this. If
it's to avoid them in the log, again, $wgDevelopmentWarnings works.
So as I already mentioned, this would force developers from turning off the whole thing.
IMO, the notices are most useful for core & extension developers testing
their code
Well, obviously, this is what this setting is for. It is NOT to hide warnings on production wikis.
Yes, I read what you wrote, I just happen to disagree with you.
If a bunch of extension developers maintaining extensions with wide compatibility requirements agree that this is not useful, then I'll revert myself. What I've seen so far are core developers apparently not being able to put themselves in the shoes of extension developers.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On Wed, Jan 11, 2012 at 2:18 PM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
If a bunch of extension developers maintaining extensions with wide compatibility requirements agree that this is not useful, then I'll revert myself. What I've seen so far are core developers apparently not being able to put themselves in the shoes of extension developers.
You're shifting responsibility here. The job of the person adding new code (you) is to convince the community (everyone else) that it's a good idea. That's how we develop. Aaron, Brion and myself have all expressed skepticism at the usefulness of this idea.
We don't develop with the model of "Well I think it's a good idea and if you can't prove me wrong then it stays."
-Chad
Hey,
You're shifting responsibility here. The job of the person adding new code (you) is to convince the community (everyone else) that it's a good idea. That's how we develop. Aaron, Brion and myself have all expressed skepticism at the usefulness of this idea.
We don't develop with the model of "Well I think it's a good idea and if
you can't prove me wrong then it stays."
Sure. If I think something is good and everyone else it's not, bad luck for me.
This feature is primarily useful for extension developers, not so much for core developers. So what we got here is a bunch of core developers saying it's not so useful. Is that surprising? No, not really, I've seen this many times before (just think about the @since tag which just got ridiculed by several core developers but makes a huge difference to extension developers). What I am asking is to keep in mind the needs of developers that do not just work on core or extension with loose or no compat restraints. If it turns out that these people disagree with me, then again, bad luck for me. But I really doubt this is the case. This setting is thought useful by the two most active extension developers. That might just mean something?
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
So as I already mentioned, this would force developers from turning off the
whole thing.
When I mentioned $wgDevelopmentWarnings, I was talking about production, which is I why I had different paragraphs. The last one was about development.
Anyway, one can bump the version in a wfDeprecated() call to delay the cycle. AFAIK, the only problem in general with delaying it is the following: a) function deprecated for version X, used by extensions A & B b) author of A checks and complains because he can't handle the change this cycle c) deprecation bumped to version X+1 in response d) author B checks and sees no warnings (since it was bumped) e) next release comes f) author of B checks and sees warnings and ALSO happens to be unable to handle the change this cycle for whatever reason. It would have been nice if he knew last cycle so maybe the time to fix could have been fit in by now. g) we either leave author B with notices or delay the deprecation version a second time
I still can't see a strong enough use case for the feature. It's not that it doesn't exist, it just seems too marginal. As with chad, I don't think it's revert war worthy.
-- View this message in context: http://wikimedia.7.n6.nabble.com/should-we-keep-wgDeprecationWhitelist-tp360... Sent from the Wikipedia Developers mailing list archive at Nabble.com.
Hey,
As with chad, I don't think it's revert war worthy.
I fully agree it is not.
c) deprecation bumped to version X+1 in response
Why would you do this? If an extension author has no time to update something, this should not affect deprecation policy in core. There might be exceptions, but in general this seems like a dumb thing to do.
It's not that it doesn't exist, it just seems too marginal.
I ran into it 3 times in the last 2 months and have 3 methods whitelisted in localsettings which I'll take care off later. It is not rare if you are about forward compatibility. Right now I have everything compatible with trunk except these 3. Without this whitelist I'd have to turn off warnings for 1.19 to be able to use my wiki without getting a pile of notices every time, in which case I'd not know yet about several changes I've already taken care off now. Note how the frequency of these whitelisted methods does not matter. One is enough to make you swicth to a not as good configured dev environment.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
My inclination is to get rid of the feature for pretty much the reason you mentioned.
In any case, is the point to avoid notices getting added to HTML for wikis with certain extensions? I don't know why a production site would be set to spew notices. Either error log settings or $wgDevelopmentWarnings can handle this. If it's to avoid them in the log, again, $wgDevelopmentWarnings works.
IMO, the notices are most useful for core & extension developers testing their code (who deliberately let all warnings get spewed out). If the dev has time to work other extensions, and has the affected one enabled on the same test wikis that have other extensions being worked on, *then* it might be useful to hide certain warnings. However, it seems better to just delay the deprecation in core a cycle. The use case for the new global just seems too marginal and it seems pretty awkward and hacky.
-- View this message in context: http://wikimedia.7.n6.nabble.com/should-we-keep-wgDeprecationWhitelist-tp360... Sent from the Wikipedia Developers mailing list archive at Nabble.com.
On 11 January 2012 19:04, Aaron Schulz aschulz4587@gmail.com wrote:
My inclination is to get rid of the feature for pretty much the reason you mentioned.
In any case, is the point to avoid notices getting added to HTML for wikis with certain extensions? I don't know why a production site would be set to spew notices. Either error log settings or $wgDevelopmentWarnings can handle this. If it's to avoid them in the log, again, $wgDevelopmentWarnings works.
IMO, the notices are most useful for core & extension developers testing their code (who deliberately let all warnings get spewed out). If the dev has time to work other extensions, and has the affected one enabled on the same test wikis that have other extensions being worked on, *then* it might be useful to hide certain warnings. However, it seems better to just delay the deprecation in core a cycle. The use case for the new global just seems too marginal and it seems pretty awkward and hacky.
I generally agree that this is not a good addition. If a developer suppresses warnings, he will then proceed to forget about the warning that was suppressed, that's just a simple fact of life. Then the whole benefit of the warning system is negated; the developer is just as likely to update their version and find that things break as if they had turned off deprecation warnings altogether.
Rather, if a developer upgrades from 1.16 to 1.17 and notices a new interface and a @deprecated warning on the old one, concludes that he cannot fix it until 1.19 is released and he can drop support for 1.16, then upgrades to 1.18 and starts getting warnings, he should hack core to remove the wfDeprecated statement from the old interface. Then when he upgrades to 1.19, the probably-now-forgotten hack is overwritten and the warnings reappear, reminding him that he should now start seriously thinking about reworking the extension code. He can then update, test and release a 1.19-compatible version of the extension before the core function itself is removed in 1.20.
--HM
r106883 introduces a new global setting to whitelist deprecated functions: $wgDeprecationWhitelist.
Reverted by r109020 https://www.mediawiki.org/wiki/Special:Code/MediaWiki/109020
wikitech-l@lists.wikimedia.org