Last modified: 2011-03-13 18:06:20 UTC
Remove majorly rotted, badly written extensions from our SVN repo
Pleas publish inclusion requirements.
Working within the past year or so might be a good idea.
Define "working"? Is that "trunk extension on trunk core" or "with any version of extension in the past year on any version of core in the past year". I would argue this needs some clarification.
We should not mass delete extensions that are old and have not been updated. Especially when the fixes (eg, r81247) are not terribly complicated. SpecialPage::addPage() is a horrible, horrible interface, but it takes about 5 minutes to fix (and really, everything in trunk using it should get fixed so we can slap a wfDeprecated() on it). Deleting random extensions is going to hurt random third party users. I cannot underline this next point enough, so it's getting it's own paragraph: People leave error reporting off on a lot of production boxes (especially if it's just throwing E_NOTICE or E_WARNING over something relatively trivial). So "broken" extensions might still appear to be fully functional to third parties. Are they bad sysadmins? Yep. But we shouldn't throw them a curveball. At the very least, they should be marked with an OBSOLETE/DEPRECATED/OLD file like we did with MakeSysop and friends as they were slowly removed. It can't hurt to have them in for a release, and then nobody can fault you for not saying anything. Now, if you have some helpful suggestions for individual extensions we should remove due to (really!) bad code, outdatedness, etc, I'm all ears. But to do it en-masse is just a Bad Idea. (In reply to comment #3) > Define "working"? Is that "trunk extension on trunk core" or "with any version > of extension in the past year on any version of core in the past year". I would > argue this needs some clarification. I've been hitting this problem incredibly often as of late. The gears are turning...we need a solution (but that's out of the scope of this and doesn't change my WONTFIX)
