WMF Gerrit hosted extensions #2080
Comments
|
+1 to removing old copies and pointing people to the current location Not sure if it is useful to have an issue about this here if there already is one on Phabricator. Also not sure if any of the involved devs still care enough at this point about what is on Gerrit to act on this issue. |
I also think that Phabricator is the place to handle this particular issue. T151968 should however have been created by us back in April. Apart from that I think this may just be a |
|
Mostly filing a task here to bring your attention to it properly :) |
|
|
I do note SemanticCompoundQueries has a MOVED.md instead |
|
I've seen claims from WMF developers that "what's not in a WMF repo, cannot be searched" which means that if you break hooks etc, then it is unlikely those will be detected and untimely break our extensions. |
|
Thanks @reedy! +2 to those changes from my side |
@reedy Is there actually a page on mw.o listing all these depreciations and removals, e.g. "ArticleAfterFetchContent", depreciated in MW 1.21, scheduled for removal in MW 1.29 etc. and allowing developers to have a look if they missed the respective e-mail on wikitech-l? |
Which is kinda true. Unless you checkout all the other repos. But then, there's so many other extensions we don't know exist. You guys are just one of the larger ecosystems that we know of. Having old copies of extensions "rotting" (that people are likely using) in the WMF Gerrit doesn't help matters. It's not like gerrit is syncing back changes from github Of course, isn't this why you should have tests? It shouldn't be core developers responsibility to go around finding all the extensions all over the place to fix them; we should just be documenting them correctly (RELEASE-NOTES etc), and making it easy for 3rd parties (like yourselves) to know what is being removed, and potentially when. Along with things like soft deprecation (@deprecated since 1.XX) for a few versions, followed by hard deprecation (emitting notices/warnings with $wgDevelopmentWarnings set to true), followed by actually removing them, which will break things. I know some people don't do that (and in some cases, either it's not used anywhere, so it can go, or maintaining that back compat becomes a huge maintenance burden that it has to happen. The latter is rare) I mean, in these cases, they were soft deprecated since 1.21, which was released 3 years ago. If people can't/won't fix things themselves after 3 years... Why should we do it for them? Even more so for extensions with active and varied development teams. Similarly, what about Wikia? Well, they've effectively forked, so bad example... What about WikiHow etc who host their own extensions? It's a best effort thing. We shouldn't expect core developers to have to checkout the 800+ extensions from gerrit, and then go around checking out (and keeping up to date) clones of many other extensions, it's just unviable. Never mind for the inexperienced, like in GCI tasks etc. It takes me long enough to update these clones on my internet connection
Not really... The individual pages will tell you when removed etc, but I don't think that's a viable way for you to get the information. Like I say, RELEASE-NOTES should contain the relevant information of what was removed (and potentially, what was deprecated in a release). Using a reasonable IDE, with correct annotation notices, it would be possible to search for deprecated code usages, and know you need to do something about them The deprecation life cycle is a bit unwritten, though I believe there was an RfC about this... https://www.mediawiki.org/wiki/Deprecation is what we have currently. Personally, I try (noting, best efforts here) to not remove anything from core, when there are still usages of it. Around a year ago we did a blitz on removing old message functions, which we did by fixing up all usages in extensions, before removing from core.... As they had been deprecated for many versions already. In some cases, with hard deprecation for numerous versions. By this point, just removing is kinda fair game if it's not hosted somewhere like gerrit where we can easily see usages need fixing |
|
I've merged all the ones that I made patches for last night... Can someone check if I missed any please? :) |
Just checked. All extensions were covered. Thanks for fluff. @reedy Thank you for your very elaborate information and you view on this! I believe this issue can now be closed as such? Though @JeroenDeDauw @mwjames we should find a way to automatically detect the depreciation warnings, perhaps by me adding |
|
I think, unit tests run with $wgDevelopmentWarnings enabled (maybe look at changing your travis config?) will surface hard deprecation notices very nicely |
|
|
Related to #2079 it'd be really useful if we could get a handle of what is canonically hosted where, and look at "deleting"/actively deprecating (empty out master, and leave an explicit README?) the WMF hosted extensions if they're not being synced between here and Gerrit
The text was updated successfully, but these errors were encountered: