Release Management RFP/2014/Consortium



Hello.

We are an international consortium of core MediaWiki and third-party developers and system administrators for several large third-party projects including ShoutWiki and Uncyclomedia. The MediaWiki release process affects us all as volunteers, developers, designers and system administrators, and we see this proposal as an opportunity to take a larger role in ensuring a release process that works for us and the companies and communities we represent. Our skills and perspectives complement each other like a five-person rock band; any one of us could not do this alone, and together we can tap an extensive community of collaborators, coworkers, end-users and friends to ensure that MediaWiki releases are well-tested, well-documented and as bug-free as possible.

What users need
MediaWiki has millions of users, who tend not to be happy when something goes wrong with new releases – as it does all too often.

For system administrators
In order to serve our user communities, we need:


 * 1) Working, tested releases
 * 2) * Releases should be tested across common configurations before release, including multiple versions of PHP, different types of databases, and other dependencies that MediaWiki supports.
 * 3) * Upgrades should work regardless of how old the previous version is – if we need to upgrade from 1.16 to 1.23, it should be possible to upgrade between these versions directly.
 * 4) * Upgrades should not break major extensions: official Foundation extensions and popular non-WMF extensions, such as Semantic MediaWiki and SocialProfile, should be tested before release, and non-functioning extensions should be clearly marked and announced.
 * 5) * Any issues that do come up with a release should be taken seriously and resolved quickly, as - despite everyone's best efforts - things do go wrong sometimes.
 * 6) Working, tested releases on time
 * 7) * Schedules should be consistent so we can plan our own upgrades accordingly.
 * 8) Working, tested releases to be announced on time
 * 9) * Announcements of both release candidates and new releases should go out on all relevant channels well in advance, not just to mailing lists such as wikitech-l, mediawiki-l, mediawiki-announce and mediawiki-enterprise, but also to the main page of MediaWiki.org.
 * 10) Working, tested releases to be documented before release
 * 11) * Updated release documentation should be easily found on MediaWiki.org, preferably linked on the main page. The original announcement should also include the necessary information and links, and should be written to be accessible to developers, system administrators and end-users.
 * 12) In-place updates to working, tested releases
 * 13) * Upgrades should not take down the entire website for the duration of the upgrade: most won't interfere with active services, and not all of our users can afford a DBA to perform schema upgrades.
 * 14) * Most updates can be done in-place. Those that cannot can often be done more efficiently, such as by initially adding with nulls, and populating them with proper values later using the job queue.
 * 15) * Most schema updates can be made optional, at least for a while.
 * 16) Well-managed lists of known regressions
 * 17) * Humans are fallible, problems are unavoidable, and each one cannot be fixed before the official release. System administrators should have the right to know if updating will break something they depend on before it breaks.

For third-party developers
MediaWiki is highly scalable and modular by design. Many third-party projects, such as wikiHow, write their own extensions and skins to provide mission-critical functionality and essential features not present in core, such as complex data handling or user IP address lookup. When these extensions break, it's a nasty situation for companies, system administrators and developers alike.

Many large MediaWiki projects are running old versions right now, some using versions that are many years old and contain publicly-disclosed security vulnerabilities that have since been fixed. In many cases, the lack of upgrades is because of custom extensions and skins that no longer work with recent releases. While not following the MediaWiki coding conventions and standards on their end can be a contributing factor, some of the problems lie in the upstream codebase as well, due to hard-to-follow release notes, lack of consistent dependency testing, and poorly executed refactorings that lead to breaking changes.

To prevent situations where the site is displaying fatals all over the place, or worse, the site never gets upgraded at all, we want to make the process as smooth as possible and encourage collaboration and cooperation between core and third party developers. Developers on all sides should encounter a straight-forward and welcoming process to provide code, receive feedback, provide suggestions and help with translations.

To begin, we would need:


 * 1) Reliable release dates
 * 2) Reliable announcements of release candidates and releases
 * 3) Notification of release blockers
 * 4) * Sometimes things go wrong, but if something is blocking a release, we can fix it – if we know about it.
 * 5) Notification of breaking changes
 * 6) * The sooner we know what we need to fix in our extensions and skins, the better. Breaking changes in core may include:
 * 7) ** New deprecations
 * 8) ** Final removals of deprecated functions (yes, they may have been announced in the past, but that doesn't mean everyone remembers)
 * 9) ** Random refactoring (there may have been a good reason for it, but this does often break things, and we need to know so we can check)
 * 10) ** Unexpectedly changing dependencies
 * 11) * All of these are supposed to be included in release notes in some fashion already, but developers don't always remember to add them. The release notes themselves are not always readable or discoverable. Input from active third-party developers – such as those involved in this proposal - would lead to better, more understandable release notes.
 * 12) Better extension versioning
 * 13) * Create REL_* branches of extensions in batches is useful, but doesn't mean they necessarily work with that version. Release branches should be properly verified to work before being published.

What we propose to do
We will do the following:
 * 1) Consistent scheduling, with long-range announcements and plans
 * 2) * Punctual releases, including security releases being made available as soon as possible
 * 3) * Complete announcements to all relevant mailing lists, including a breakdown of potentially breaking changes
 * 4) Thorough testing before releases: multiple PHP versions, different operating systems and databases, and against common extensions
 * 5) * Bug filing and fixes
 * 6) * Communication with extension developers and maintainers regarding things that will need fixing, with suggestions where practical
 * 7) Making the release tarballs, with major releases going out on a six-month cycle
 * 8) Security and bugfix releases as they come up
 * 9) Creating basic documentation on-wiki
 * 10) * Release documentation
 * 11) * Guides for sysadmins and developers for updates
 * 12) * Guides for sysadmins for difficult but useful extensions (such as VisualEditor)
 * 13) * Documentation of what we do as release managers
 * 14) Development of automated testing infrastructure
 * 15) Anti-spam improvements
 * 16) * Bundling anti-spam extensions with the tarball, and providing configurations for them with sensible defaults
 * 17) * AbuseFilter repository with performant and functional anti-spam filters

We also plan to work on the following, but as a lower priority:
 * 1) Outreach to relevant parties
 * 2) * Package maintainers (including Debian, Arch and others)
 * 3) * Third-party system administrators, including enterprise, volunteer projects, folks using WMF branches, folks who need security, folks still on 1.16, folks with skins that won't update, folks with horrible spam problems ...
 * 4) * Non-community developers
 * 5) Relevant MediaWiki development
 * 6) * Improved backend and skinning support
 * 7) * Extensions
 * 8) ** Maintenance for unsupported but widely-used extensions
 * 9) ** Better packaging and documentation for third-party users (especially for important extensions such as VisualEditor and MobileFrontend)
 * 10) Improved mechanisms for keeping skins and extensions up to date and functional along with the MediaWiki installation

Fallback, or what we would do should funding implode
This is what could be done for free by volunteers. It is how MediaWiki's release process has been handled in the past, as well as how other projects such as the Signpost continue to work - reasonably consistently, but not anyone's priority.

The following are included:
 * Eventually making the release tarball and signing it, with releases going out on the current schedule
 * Making release candidates
 * Security and bugfix releases whenever anyone gets around to it
 * Sending out the announcements

Issues:
 * Testing is not guaranteed
 * Security releases may be slow
 * Announced dates may not be honoured due to volunteer priorities

Kim Schoonover


Kim is a system administrator, software developer and UI designer for all Uncyclomedia websites and ShoutWiki. She has developed several complex skins - including ShoutWiki's Aurora skin, Greystuff, and Splash – and UI improvements for MediaWiki, and has contributed to MediaWikiAuth extension. She led the 2012 move of Uncyclopedia's large database to another server, coordinating volunteers and developing wiki grabber scripts to successfully complete this unprecedented move. She lives in the US.

Kim's experience with herding cats makes her ideal to manage each release, making sure that testing is complete, that the community is satisfied with the release candidate and that the appropriate mailing lists are notified and websites updated. She will also handle uploading the tarball and associated tasks.

Ryan Schmidt


Ryan is an experienced MediaWiki developer and system administrator. He wrote Extension:SimpleAntiSpam and improved permission handling via $wgRevokePermissions, both of which were eventually incorporated into core. He is experienced with developing for third-party wikis running unconventional configurations: he added MS-SQL support to core (again) and has worked on many other extensions. He was one of the original staff at ShoutWiki (where he helped write the CreateWiki utility), is a system administrator for Uncyclomedia websites, and runs thetestwiki.org. He provides paid consultancy in installing and configuring MediaWiki, integrating it with custom software, and writing custom MediaWiki extensions. He is well-known in both MediaWiki developer and system administrator community, especially from his time as an administrator and active user on the mwusers.org support forum. He lives in the US.

Ryan's extensive background in databases and system architecture will put him right at home working on testing frameworks to ensure that the tarball works correctly on a variety of platforms, and that upgrades from arbitrary MediaWiki versions work without issue.

Benjamin Lees


Benjamin is a long-time MediaWiki system administrator and developer with extensive experience in supporting users of MediaWiki. Benjamin has provided support to third-party users of MediaWiki for years on the mwusers.org forum, the mediawiki-l mailing list, the MediaWiki.org support desk, and the #mediawiki IRC channel. He is the author of Extension:QuestyCaptcha, a popular CAPTCHA plugin, and is based in the US.

Benjamin's established position in the community makes him an excellent point-man in gathering and managing feedback on releases and the release process.

Jack Phoenix


Jack Phoenix is an experienced developer of MediaWiki core, extensions, and skins. He has been developing MediaWiki since 2008, is a primary maintainer for ShoutWiki and its many associated extensions, and has developed more extensions and skins both as a ShoutWiki employee and as a volunteer than even he can keep track of anymore. He successfully advocated for and assisted in the open-sourcing of ArmchairGM's codebase, regular publishing of wikiHow's source code dumps, and publishing the entirety of Wikia's codebase under a free and open source license. He leads the customer support staff at ShoutWiki, where he works closely with users and MediaWiki community managers. He has extensive experience in working with translations and lives in Finland.

Jack will continue to liaison with third party users such as Wikia and wikiHow during the release, and will work on making MediaWiki releases easier for non-WMF users to use.

Bartosz Dziewoński
Bartosz is an experienced MediaWiki core developer with +2 rights on the Gerrit repository, several hundred merged commits and several hundred more reviewed and merged. He is knowledgeable on nearly every aspect of MediaWiki, from the parser through category collations to skin handling and frontend scripting. He has contributed to previous MediaWiki releases by writing and backporting patches and triaging bugs for supported release versions. He is based in Poland.

As an experienced developer, Bartosz will work on the multitude of Gerrit and Bugzilla activities that are associated with resolving bugs and writing and reviewing patches for them.