Performing maintenance
Anyone who has worked with MediaWiki can tell you that the maintenance scripts are not the most-maintained bits of code. Most of them still work, at least to some degree, but there are certainly bugs that need fixing, and the code is rather outdated and certainly not flexible to improvements. I decided to embark on this with the filing of bug 19133. The following bit is copied from the project page on MediaWiki.org:
The overall goal of this project is to improve the overall situation of the maintenance directory. Right now, things are unorganized, undocumented and do not follow any real standard. As a result, scripts are hard to maintain and support. The maintenance-work branch aims to fill the following goals:
- Standardize – All supported maintenance scripts should follow the standards outlined in the official docs. In addition, scripts should follow MW coding conventions with variable naming
- Documentation – All maintenance scripts should have a proper description, as well as documentation of all parameters. In addition, appropriate code documentation needs to exist for the auto-generated code docs.
- Cleanup – Some scripts are outdated, these need to be clearly marked as such or removed.
- Bugfixing – There’s a short list of filed bugs for maintenance scripts. Some of these can be easily fixed while we’re already under the hood.
It would be nice at some point to have all of this clean & standardized to a point where an extension like Maintenance can work without major drawbacks. In addition, the rewrite is not looking to work with any of the following:
- The update/install process. Tim was looking at a rewrite/cleanup here eventually, and I’m not looking to step on toes.
- Database abstraction. Where quick fixes can be done, they will be integrated. However, the maintainers of the different database ports should be on top of fixing broken SQL for their interfaces.
So that’s that. I’ve got a decent number of things done so far (commits), and I hope to be finishing this sometime in the coming weeks. I linked the page above (and here it is again) where all the information about the branch and transition process can be found. I would love to get some solid input from fellow developers and third-party users about likes/dislikes of the new plan, things that can be improved or fixed, et cetera.
On a completely unrelated note: I had Unix training at work today. The training consisted of an hour discussion about vi and a handout of the entire vi man pages. Great tips, but hardly relevant to my job’s usage of Unix.
