Patch to remove: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/447647 Bug: https://phabricator.wikimedia.org/T200247 Existing uses: https://codesearch.wmflabs.org/search/?q=MagicWord%3A%3AclearCache&i=nop...
I'm in the middle of creating a MagicWordFactory service to replace the MagicWord static methods. This obsoletes the clearCache() method. Instead, just reset the service with resetServiceForTesting(). Since clearCache() is used in only three places in public code, and is only useful to begin with for tests, and the fix is trivial, I propose removing it without deprecation rather than bothering to maintain code for compatibility.
There have been several proposals for removal without deprecation in the past few days, each with more impact on existing code - from "virtually certain nobody ever used" to "the fix is trivial".
I know it is annoying as heck to keep outdated code, but if you ask me, unless there is an immediate compelling reason for the removal the deprecation policy should not be bypassed. And in my opinion "I did not find any extension that uses this method" is not sufficient. Not all extensions/skins are hosted on WMF servers. And being trivial to fix does not help, either. It would be great if everybody could monitor MW master, run CI tests regularly for all their extensions and fix any breakages. Unfortunately many people do not have the time to do that, so they need the deprecation period (and at times the deprecation popups to even notice that something is wrong).
So, I would request to keep the clearCache() method for the foreseen deprecation period. (And generally speaking, though not explicitly required by the deprecation policy and probably not applicable in this instance, it would be great if deprecated methods would actually be kept in working condition and not reduced to a (literally) empty husk just to stay in line with the letter of the policy.)
Stephan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On July 30, 2018 2:51 PM, Aryeh Gregor ayg@aryeh.name wrote:
Patch to remove: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/447647 Bug: https://phabricator.wikimedia.org/T200247 Existing uses: https://codesearch.wmflabs.org/search/?q=MagicWord%3A%3AclearCache&i=nop...
I'm in the middle of creating a MagicWordFactory service to replace the MagicWord static methods. This obsoletes the clearCache() method. Instead, just reset the service with resetServiceForTesting(). Since clearCache() is used in only three places in public code, and is only useful to begin with for tests, and the fix is trivial, I propose removing it without deprecation rather than bothering to maintain code for compatibility.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jul 30, 2018 at 4:28 PM, Stephan Gambke via Wikitech-l wikitech-l@lists.wikimedia.org wrote:
There have been several proposals for removal without deprecation in the past few days, each with more impact on existing code - from "virtually certain nobody ever used" to "the fix is trivial".
I know it is annoying as heck to keep outdated code, but if you ask me, unless there is an immediate compelling reason for the removal the deprecation policy should not be bypassed. And in my opinion "I did not find any extension that uses this method" is not sufficient. Not all extensions/skins are hosted on WMF servers. And being trivial to fix does not help, either. It would be great if everybody could monitor MW master, run CI tests regularly for all their extensions and fix any breakages. Unfortunately many people do not have the time to do that, so they need the deprecation period (and at times the deprecation popups to even notice that something is wrong).
So, I would request to keep the clearCache() method for the foreseen deprecation period. (And generally speaking, though not explicitly required by the deprecation policy and probably not applicable in this instance, it would be great if deprecated methods would actually be kept in working condition and not reduced to a (literally) empty husk just to stay in line with the letter of the policy.)
I personally have maintained local hacks to various software packages in the past, and definitely symphathize with the headache of having to keep up-to-date. However, the deprecation policy doesn't try to help people who aren't keeping up-to-date. It will just postpone their extension's breakage by two releases, not decrease the overall amount of work they have to do. The deprecation policy is just to give extension maintainers a bit of breathing room so they don't have to scramble to update their extension before it breaks.
As far as these specific proposals, the wording of the deprecation policy suggests that removal without deprecation should only be cases where it's absolutely necessary. I think we should also allow such removal when it seems probable that basically nobody actually used the feature. For instance, the feature being removed in this case is only useful for tests of MagicWords. It doesn't seem worth the hassle to go through a whole procedure to remove it if it will probably affect nobody, and almost certainly affect at most one or two people, and the affected parties will just have to make a one-line change. I'm not saying the burden on extension developers will be zero, but a lot more time will be needed for us to follow the procedure than we'd save anyone.
of work they have to do. The deprecation policy is just to give extension maintainers a bit of breathing room so they don't have to scramble to update their extension before it breaks.
Exactly. It also makes it easier for them to maintain their extensions for more than the last version of MW.
As far as these specific proposals, the wording of the deprecation policy suggests that removal without deprecation should only be cases where it's absolutely necessary. I think we should also allow such removal when it seems probable that basically nobody actually used the feature.
There are three "probability qualifiers" in that sentence (seems, probable, basically). You just don't know if somebody now has to fix their code. And one benefit of having a spelled out policy is to make sure that not only the high-profile breaking changes are properly treated but also the small ones.
For instance, the feature being removed in this case is only useful for tests of MagicWords. It doesn't seem worth the hassle to go through a whole procedure to remove it if it will probably affect nobody, and almost certainly affect at most one or two people, and the affected parties will just have to make a one-line change.
It is a one-line change from your perspective. For the maintainer it will be picking up the extension after some time, fixing some unrelated bug, running the tests and have them fail. Finding the problem should be easy enough (method not found), but they then have to investigate, why that stupid method is missing all of a sudden and find and understand the recommended solution, digging through commits and phabricator tickets. They then need to apply the solution which, if they want clean self-contained commits, includes committing or stashing their current code, opening a new branch, applying the fix, running the test, merging the branch to master, picking up the original branch and rebasing it. All of this on top of the small bug fix they actually came for.
I am aware that I am talking hypothetics here. You are probably right that nobody out there is using this particular method and even if so, then their production code will not immediately stop working. So, by all means use your best judgement and go ahead if you think removing the method is justified. But please keep in mind that any time you safe when bypassing the procedure may mean more hassle down the line.
Cheers Stephan
On Tue, Jul 31, 2018 at 10:43 AM, Stephan Gambke s7eph4n@protonmail.com wrote:
There are three "probability qualifiers" in that sentence (seems, probable, basically). You just don't know if somebody now has to fix their code.
Correct -- I can't know, because they didn't put their code in a place where code search finds it. What we can deprecate or remove and how quickly is always a guess vis-a-vis extensions that we can't see. I *do* know that it would be a significant hassle to go through the deprecation procedure for every ancient crufty method from 2004 (or whatever) that we want to get rid of. We would be paying a definite cost for a gain that might not even exist.
So we have to make a trade-off between the burden on extension developers and on core developers. When it seems likely that basically no non-public extension/skin uses the feature, I think it's reasonable to say that we should do what's easiest for core developers. If a few people out there who didn't put their extensions where we can see them have to go to some trouble, that's life.
It is a one-line change from your perspective. For the maintainer it will be picking up the extension after some time, fixing some unrelated bug, running the tests and have them fail. Finding the problem should be easy enough (method not found), but they then have to investigate, why that stupid method is missing all of a sudden and find and understand the recommended solution, digging through commits and phabricator tickets. They then need to apply the solution which, if they want clean self-contained commits, includes committing or stashing their current code, opening a new branch, applying the fix, running the test, merging the branch to master, picking up the original branch and rebasing it. All of this on top of the small bug fix they actually came for.
You're right, but all that is just as true if we had deprecated the feature per the policy. You're talking about someone who didn't check the release notes before upgrading to find out if his extension used any removed features, so presumably he also doesn't check the release notes for deprecated features. Either way, the release notes do say that it was removed (easily searchable by method name) and what to do instead. (Although in this case I think the "what to do instead" in the release notes could be improved upon.)
So we have to make a trade-off between the burden on extension developers and on core developers. When it seems likely that basically no non-public extension/skin uses the feature, I think it's reasonable to say that we should do what's easiest for core developers. If a few people out there who didn't put their extensions where we can see them have to go to some trouble, that's life.
I agree that there is a trade-off to be done. I disagree about expecting code to be put where it is visible to core developers. I do appreciate that you go and look for where the functionality that you are working on is used outside core. But ultimately MW is publishing a public interface and it is unreasonable to expect all consumers of that interface to "register" and publish their code as well.
It is a one-line change from your perspective. For the maintainer it will be picking up the extension ...
You're right, but all that is just as true if we had deprecated the feature per the policy.
The difference is that in that case the test would have run through, throwing just a notice and the call to the deprecated function could have been removed another day. Of course, if they did not want to deal with breakages, that maintainer should not have pulled MW master in the first place and should have just worked on whatever MW version they left off of a few months ago when they last worked on their extension.
You're talking about someone who didn't check the release notes before upgrading to find out if his extension used any removed features, so presumably he also doesn't check the release notes for deprecated features. Either way, the release notes do say that it was removed (easily searchable by method name) and what to do instead. (Although in this case I think the "what to do instead" in the release notes could be improved upon.)
True. I don't know how other people do it, but I usually only scan the release notes for big changes and otherwise rely on deprecation notes to pop up. Doing otherwise would require me to maintain a register of all MW core functions called from my extensions and cross-checking it by hand.
Stephan
On Tue, Jul 31, 2018 at 3:46 PM, Stephan Gambke s7eph4n@protonmail.com wrote:
I agree that there is a trade-off to be done. I disagree about expecting code to be put where it is visible to core developers. I do appreciate that you go and look for where the functionality that you are working on is used outside core. But ultimately MW is publishing a public interface and it is unreasonable to expect all consumers of that interface to "register" and publish their code as well.
We don't, but if they don't publish it we have to guess at what will or won't break it, which means there's a higher chance that we will break it.
The difference is that in that case the test would have run through, throwing just a notice and the call to the deprecated function could have been removed another day.
Hard-deprecation fails the test completely, right?
Of course, if they did not want to deal with breakages, that maintainer should not have pulled MW master in the first place and should have just worked on whatever MW version they left off of a few months ago when they last worked on their extension.
Correct, we do not and should not go out of our way to make life easy for people running unstable MediaWiki. It's not meant for production unless you're following development closely and are prepared to deal with breakage.
True. I don't know how other people do it, but I usually only scan the release notes for big changes and otherwise rely on deprecation notes to pop up. Doing otherwise would require me to maintain a register of all MW core functions called from my extensions and cross-checking it by hand.
Indeed, but as soon as you see the error message, it's easy to check the release notes/history to figure out what to do. Deprecation/removal notices there should say what the replacement is as clearly as possible. (If they don't, that's a separate problem.)
So to give my perspective as an "outsider":
My day to day job is to write MediaWiki extensions for a wiki-farm called Liquipedia. We are mostly hopping LTS version, so even deprecation for two versions doesn't necessarily mean much to us here. Generally I just install a new MediaWiki version on dev and then test all of our extensions thewre until they work, without bothering the live version of our wikis.
The talk here seems to be mostly about people that "blindly" upgrade their wiki, and I agree there will always be issues with those, no matter the deprecation method. If you don't update to every version, you might never see a deprecation notice, as the next version you are upgrading to is not necessarily the next version of MediaWiki released, and if you are updating to every version you might still not be able to fx your own extensions or you might not even check for deprecation notices (mind they only show up with the right dev params).
I totally agree on directly removing functions that have been functionless for years like the one we had recently that didn't work since sometime 2009 or so, no question about that, but I'm not so sure about working functions.
There is a lot of consideration going into writing MediaWiki extensions, and there might be good reasons to not host a MediaWiki extension on Wikimedia git repositories. I have seen very specialized MediaWiki extensions that would not work without outside code (especially extensions allowing login with outside userdatabases and extensions querying certain internal APIs come to mind), so I don't think using only Wikimedia hosted repositories is a good indication. Generally I think deprecation periods that are supposed to actually be helpful should always pass at least one LTS release, as those reach a bigger audience.
Deprecation wise, I personally feel like it only makes a difference if deprecations always survive the next LTS release, as most less regular wiki owners are likely to jump LTS versions. If there is no waiting for LTS releases, then deprecation is somewhat pointless in my point of view, since these policies are mostly in place for third party wikis.
I hope this point of view is helpful to you, if there are any further questions regarding our own workflow, feel free to ask and I'll try to answer to the best of my ability.
Alex "FO-nTTaX" Winkler
Head of Liquipedia Development https://liquipedia.net/ - https://www.teamliquid.com/
Am 31.07.2018 um 14:53 schrieb Aryeh Gregor:
On Tue, Jul 31, 2018 at 3:46 PM, Stephan Gambke s7eph4n@protonmail.com wrote:
I agree that there is a trade-off to be done. I disagree about expecting code to be put where it is visible to core developers. I do appreciate that you go and look for where the functionality that you are working on is used outside core. But ultimately MW is publishing a public interface and it is unreasonable to expect all consumers of that interface to "register" and publish their code as well.
We don't, but if they don't publish it we have to guess at what will or won't break it, which means there's a higher chance that we will break it.
The difference is that in that case the test would have run through, throwing just a notice and the call to the deprecated function could have been removed another day.
Hard-deprecation fails the test completely, right?
Of course, if they did not want to deal with breakages, that maintainer should not have pulled MW master in the first place and should have just worked on whatever MW version they left off of a few months ago when they last worked on their extension.
Correct, we do not and should not go out of our way to make life easy for people running unstable MediaWiki. It's not meant for production unless you're following development closely and are prepared to deal with breakage.
True. I don't know how other people do it, but I usually only scan the release notes for big changes and otherwise rely on deprecation notes to pop up. Doing otherwise would require me to maintain a register of all MW core functions called from my extensions and cross-checking it by hand.
Indeed, but as soon as you see the error message, it's easy to check the release notes/history to figure out what to do. Deprecation/removal notices there should say what the replacement is as clearly as possible. (If they don't, that's a separate problem.)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I favor deprecating functions. I'm sure you're familiar with https://xkcd.com/1172/
Have a great day, Bart Humphries bart.humphries@gmail.com (909)529-BART(2278) <9095292278>
On Tue, Jul 31, 2018 at 3:16 PM, Alex Winkler fonttax@teamliquid.net wrote:
So to give my perspective as an "outsider":
My day to day job is to write MediaWiki extensions for a wiki-farm called Liquipedia. We are mostly hopping LTS version, so even deprecation for two versions doesn't necessarily mean much to us here. Generally I just install a new MediaWiki version on dev and then test all of our extensions thewre until they work, without bothering the live version of our wikis.
The talk here seems to be mostly about people that "blindly" upgrade their wiki, and I agree there will always be issues with those, no matter the deprecation method. If you don't update to every version, you might never see a deprecation notice, as the next version you are upgrading to is not necessarily the next version of MediaWiki released, and if you are updating to every version you might still not be able to fx your own extensions or you might not even check for deprecation notices (mind they only show up with the right dev params).
I totally agree on directly removing functions that have been functionless for years like the one we had recently that didn't work since sometime 2009 or so, no question about that, but I'm not so sure about working functions.
There is a lot of consideration going into writing MediaWiki extensions, and there might be good reasons to not host a MediaWiki extension on Wikimedia git repositories. I have seen very specialized MediaWiki extensions that would not work without outside code (especially extensions allowing login with outside userdatabases and extensions querying certain internal APIs come to mind), so I don't think using only Wikimedia hosted repositories is a good indication. Generally I think deprecation periods that are supposed to actually be helpful should always pass at least one LTS release, as those reach a bigger audience.
Deprecation wise, I personally feel like it only makes a difference if deprecations always survive the next LTS release, as most less regular wiki owners are likely to jump LTS versions. If there is no waiting for LTS releases, then deprecation is somewhat pointless in my point of view, since these policies are mostly in place for third party wikis.
I hope this point of view is helpful to you, if there are any further questions regarding our own workflow, feel free to ask and I'll try to answer to the best of my ability.
Alex "FO-nTTaX" Winkler
Head of Liquipedia Development https://liquipedia.net/ - https://www.teamliquid.com/
Am 31.07.2018 um 14:53 schrieb Aryeh Gregor:
On Tue, Jul 31, 2018 at 3:46 PM, Stephan Gambke s7eph4n@protonmail.com wrote:
I agree that there is a trade-off to be done. I disagree about expecting code to be put where it is visible to core developers. I do appreciate that you go and look for where the functionality that you are working on is used outside core. But ultimately MW is publishing a public interface and it is unreasonable to expect all consumers of that interface to "register" and publish their code as well.
We don't, but if they don't publish it we have to guess at what will or won't break it, which means there's a higher chance that we will break it.
The difference is that in that case the test would have run through,
throwing just a notice and the call to the deprecated function could have been removed another day.
Hard-deprecation fails the test completely, right?
Of course, if they did not want to deal
with breakages, that maintainer should not have pulled MW master in the first place and should have just worked on whatever MW version they left off of a few months ago when they last worked on their extension.
Correct, we do not and should not go out of our way to make life easy for people running unstable MediaWiki. It's not meant for production unless you're following development closely and are prepared to deal with breakage.
True. I don't know how other people do it, but I usually only scan the
release notes for big changes and otherwise rely on deprecation notes to pop up. Doing otherwise would require me to maintain a register of all MW core functions called from my extensions and cross-checking it by hand.
Indeed, but as soon as you see the error message, it's easy to check the release notes/history to figure out what to do. Deprecation/removal notices there should say what the replacement is as clearly as possible. (If they don't, that's a separate problem.)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
I don't have a strong opinion about the specific function in this case, but I did want to discuss a few things about the policy itself.
On 07/30/2018 06:28 AM, Stephan Gambke via Wikitech-l wrote:
I know it is annoying as heck to keep outdated code, but if you ask me, unless there is an immediate compelling reason for the removal the deprecation policy should not be bypassed.
Just to be a bit pedantic here to ensure there isn't confusion - the *policy* is not being bypassed. The policy has a provision for "removal without deprecation"[1], which Aryeh is following here. The deprecation *period* is being bypassed.
And in my opinion "I did not find any extension that uses this method" is not sufficient. Not all extensions/skins are hosted on WMF servers.
If your extensions/skins are public, it's trivial to get them included in codesearch[2] - if your code isn't on Gerrit, it can be added to[3].
The policy states: "Extensions that are open source will be given more consideration than those that core developers cannot see." So it's really in extension developers best interest to make their code visible to core developers.
[1] https://www.mediawiki.org/wiki/Deprecation_policy#Removal_without_deprec ation [2] https://codesearch.wmflabs.org/ [3] https://github.com/MWStake/nonwmf-extensions
- -- Legoktm
wikitech-l@lists.wikimedia.org