Hi,
Recently in the discussions about PHP version support, there have been some brief tangents about whether MediaWiki should continue to have LTS releases and what exactly those releases should entail. I'm writing this to document the current state of LTS in MediaWiki, explain why I use the LTS release, and what I'd like to see going forward.
The status quo is that we have an LTS release every 4 versions/2 years (1.19, 1.23, 1.27, etc.). It receives bug and security fixes for 3 years, so people have a year to upgrade from one LTS to the next. There's also some other stuff on-wiki[1] about special release notes handling.
From a quick perusal of the 1.23 release notes[2], nearly all of the
backports are security related, with a few major bug fixes (e.g. fixing InstantCommons). I'd make a quick guess that there plenty of bug fixes that have happened to master since the branchpoint that could be easily backported, but aren't.
All of the non-dev wikis (and wiki farms!) that I help run currently run 1.23.x. My main reason for doing so is that upgrading major versions usually takes a few hours for each wiki. They have custom (often non-published) code or non-Wikimedia deployed extensions that typically break and require some kind of fixing. Then there's schema changes, JS/CSS changes, etc. It adds up to something that I don't want to do every 6 months. (Maybe it would be easier if I did it every 6 months? I'm not sure.)
Really all I want is a longer support for some arbitrary predetermined version with regards to security issues so I have to upgrade major versions less often. :-)
I think LTS is a significant factor to consider when deciding our PHP version requirements as there is a huge difference between saying we're going to support PHP 5.4 (or whatever) for 1 year versus 3 years.
I think it would be helpful if other people who use LTS could share their motivations for doing so, and if the release/security teams could share what issues make LTS release support problematic or difficult (a few things have been mentioned on IRC, but I'll let those people speak for themselves).
[1] https://www.mediawiki.org/wiki/Version_lifecycle#Release_policy [2] https://phabricator.wikimedia.org/diffusion/MW/browse/REL1_23/RELEASE-NOTES-...
Thanks, -- Legoktm
On Thu, Dec 3, 2015 at 1:25 AM Legoktm legoktm.wikipedia@gmail.com wrote:
I think it would be helpful if other people who use LTS could share their motivations for doing so, and if the release/security teams could share what issues make LTS release support problematic or difficult (a few things have been mentioned on IRC, but I'll let those people speak for themselves).
The main problem with supporting LTS in security releases is after they start to get old, backporting of those patches becomes a real chore for each release. 1.19 especially required a *lot* of wrangling on each release to get things back-portable because of the amount of code that had changed in the meantime. Most of the comments I've made re: LTSes have happened when working on a nasty backport so take them with a grain of salt.
This should not be a problem though. The release pipeline needs more cleanup and automation so we don't have to worry about backporting unless it actually causes conflicts (save the human labor for things a script can't figure out).
If I can find the cycles to fix this, 95% of my complaint with an LTS goes away. The other 5% is ideological and I can deal with it ;-)
-Chad
One of the key reasons I use and recommend LTS is that upgrading version to version can sometimes be a nightmare. Off hand I can think of the composer and skin repo changes that each took 1-2 hours to figure out and fix. Many of the users who use MediaWiki on either intranets or lesser hosting sites do not have a lot in regards to knowledge/support. Getting them to upgrade every two years is hard enough, let alone every six months. Having a stable platform that can be recommended as an easy go to, can be key in whether mediawiki is chosen or a different platform is picked. Ops teams dont want to be messing with testing and deploying updates every 6 months, as it will become a time sink. A LTS option enables minor updates that only take a few minutes to deploy, and 1/4 the number of upgrades.
On Thu, Dec 3, 2015 at 10:34 AM, Chad innocentkiller@gmail.com wrote:
On Thu, Dec 3, 2015 at 1:25 AM Legoktm legoktm.wikipedia@gmail.com wrote:
I think it would be helpful if other people who use LTS could share their motivations for doing so, and if the release/security teams could share what issues make LTS release support problematic or difficult (a few things have been mentioned on IRC, but I'll let those people speak for themselves).
The main problem with supporting LTS in security releases is after they start to get old, backporting of those patches becomes a real chore for each release. 1.19 especially required a *lot* of wrangling on each release to get things back-portable because of the amount of code that had changed in the meantime. Most of the comments I've made re: LTSes have happened when working on a nasty backport so take them with a grain of salt.
This should not be a problem though. The release pipeline needs more cleanup and automation so we don't have to worry about backporting unless it actually causes conflicts (save the human labor for things a script can't figure out).
If I can find the cycles to fix this, 95% of my complaint with an LTS goes away. The other 5% is ideological and I can deal with it ;-)
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thursday, December 3, 2015, Chad innocentkiller@gmail.com wrote:
On Thu, Dec 3, 2015 at 1:25 AM Legoktm <legoktm.wikipedia@gmail.com javascript:;> wrote:
I think it would be helpful if other people who use LTS could share their motivations for doing so, and if the release/security teams could share what issues make LTS release support problematic or difficult (a few things have been mentioned on IRC, but I'll let those people speak for themselves).
The main problem with supporting LTS in security releases is after they start to get old, backporting of those patches becomes a real chore for each release. 1.19 especially required a *lot* of wrangling on each release to get things back-portable because of the amount of code that had changed in the meantime. Most of the comments I've made re: LTSes have happened when working on a nasty backport so take them with a grain of salt.
When I was doing backports to 1.19, one of the most labor intensive parts was having to ensure the patch was php 5.2 compatible, when the security patches included 5.3 syntax in the other branches. So if we do LTS's, I would vote that we try to keep the php version the same for the LTS and following 3 non-LTS releases, if possible.
I personally like the idea of LTS. The last non-work wiki I setup I initially installed with 1.23, in the hopes that it would be stable with no new features. It was for collaboration on a specific project, and the users were not wikipedians-- they didn't want new features, just wanted it to work, and to be able to add stuff there once they had figured out how to use it. In then end, they also wanted VE, so I had to install a -wmf branch that mostly worked with the current parsoid, and I pretty much didn't touch it after I got it working except to apply any security patches that addressed an actual risk.
wikitech-l@lists.wikimedia.org