Talk:MediaWiki 1.5 upgrade

Just wondering: why exactly do you have to lock the database? You're doing some conversion? -- Patrice 11:09, 27 Jun 2005 (UTC)

From the release notes:

The core table schema has changed significantly. This should make better use of the database's cache and disk I/O, and make significantly speed up rename and delete operations on pages with very long edit histories.

Unfortunately this does mean upgrading a wiki of size from 1.4 will require some downtime for the schema restructuring, but future storage backend changes should be able to integrate into the new system more easily. --VampWillow 11:33, 27 Jun 2005 (UTC)

Info for our own upgrades?

Just wondering where we can go for information on our own upgrades. I've just upgraded our in-house KB wiki to 1.5rc4. The upgrade page said everything worked fine, and I can access the wiki. I can look in the database and see the records still there. But none of the pages are listed. I have no idea to fix it. Is there any where like a forum which is monitored and people may respond? So far my only option is to put 1.4 back on but we really need the user management features in 1.5

Choice of upgrade

• From the notice page it says the upgrade is to MediaWiki 1.5 Beta.
• On the SouceForge release note for MediaWiki 1.5 beta 1 it tells us :
  MediaWiki 1.5 beta 1 is a preview release, pretty much feature complete, of the new 1.5 release series. There are several known and likely a number of unknown bugs; it is not recommended to use this release in a production environment but would be recommended for testing in mind of an upcoming deployment.

If we aren't recommending that it is used in a production environment, why the hell are we rolling it out over all installations? !! --VampWillow 11:29, 27 Jun 2005 (UTC)

We don't recommend that members of the public, who don't know what they're doing, install a beta and leave it sitting there forever. (People do that, and find themselves victims of exciting bugs and security holes that were fixed in the release.)

We're actively maintaining the software, fixing bugs and installing the fixes for those bugs live. This process is part of making the software release-ready for the public who aren't actively maintaining and developing the software. --brion 11:40, 27 Jun 2005 (UTC)

I accept that you/we are in the best position to sort out any problems that arise, but I strongly question the installation of a "beta" on *all* sites in one go. It seems like a recipe for disaster and a collapse of all projects together ... --VampWillow 12:13, 27 Jun 2005 (UTC)

It's not all in one go, but one at a time, working out the kinks as we go. --brion 12:23, 27 Jun 2005 (UTC)

I should also point out the the whole existence of release versions and markings like 'beta' on MediaWiki is for third-party users of the software. MediaWiki is primarily our in-house software; we call it 'beta' when we feel it's ready for us to take it live on our sites. That's been our release naming convention as long as we've had version numbers (last year and a half or so). So if I seem confused by the question, it's because "beta" is exactly the time we'd be putting it live. --brion 12:34, 27 Jun 2005 (UTC)

MediaWiki 1.5

How do you update these sites? No, seriously, I'm interested. --Wack'd About Wiki

The index.php has been replaced with a wrapper script which checks the conversion status lists and then runs either MediaWiki 1.4 (if not converted or in progress) or 1.5 (if completed). The 1.4 configuration checks for in-progress conversions and kicks in read-only mode.

The lists and running of the upgrade script is described a bit at: http://wp.wikidev.net/1.5_upgrade

Here's the upgrader script, and a description of the process needed to avoid breaking the servers. After this specialized script runs, the generic update.php runs a few final fixups and updates the localizations.

For the old Latin-1-encoded wikis, the upgrader step also performs some conversions of data to UTF-8, but the main page text is converted on the fly when loaded, so the bulk of the data doesn't have to be modified, just the surrounding metadata structure. (Even so it's slow to work through some of the bigger wikis, unfortunately.) --brion 12:28, 27 Jun 2005 (UTC)

"Exact estimate"?

We don't have an exact estimate,

"Exact estimate". Interesting phrase. What exactly is an "exact estimate"? 128.101.152.77 20:54, 27 Jun 2005 (UTC)

"Will it be done by midnight UTC?" <- such as that. --brion 22:47, 27 Jun 2005 (UTC)

• Midnight before June 28
• Midnight before June 29.
• Midnight before June 30.
• Midnight before July.
• Midnight before August.
• Midnight before 2006.
• Midnight before 2100.

Anticipation

Was this locking during an upgrade anticipated, or did the decision to do the upgrade happen one minute before everything was locked? 128.101.152.77 21:43, 27 Jun 2005 (UTC)

Planned for quite some time ahead. The exact moment of locking was not fixed, but an upgrade this weekend was announced a week ahead and wikis have been being incrementally upgraded for the last couple of days. --brion 22:15, 27 Jun 2005 (UTC)

The message "All Wikimedia servers are having their software upgraded; thus, Wikipedia will become uneditable for a while at some point." was displayed at the top of all Wikipedia pages for some time beforehand. Factitious 23:28, 27 Jun 2005 (UTC)

Length of upgrade time

If your estimate of how long it is going to take to upgrade the English language Wikipedia is anything to go by, are you not risking losing an awful lot of useful contributions in the "months" that the site is down for?

Given that locking the content for that length of time is such a massive retrograde step in terms of the functionality of the site, is there no way that some thought could have been given to implementing record-level, rather than site-level, locking? In other words, an article on the old system would be in three states: 1) already updated, in which case a link would automatically have been inserted (statically or dynamically) into the 1.4 article linking to the 1.5 version which could then be edited; 2) in the process of being updated, in which case no editing would be possible and no link would be provided; 3) not yet updated, in which case updates could still be done on the 1.4 version? Kennethmac2000 22:11, 27 Jun 2005 (UTC)

OK, since I wrote that first piece, the estimated upgrade time for en.wikipedia.org has gone from a "few months", to a "few weeks", to a "few days", which doesn't seem quite so bad. :-) Would still be interesting to hear anyone's thoughts on my above suggestion though. Kennethmac2000 22:13, 27 Jun 2005 (UTC)

The read-only time is relatively short (our absolute longest, largest wiki is locked for the longest time, roughly a day), and all other wikis remain open for editing during the time whichever wiki is being upgraded is upgraded.

Fancier upgrade schemes are hypothetically possible, but much harder to do with our old crappy database schema, where consistency is difficult to maintain. --brion 22:14, 27 Jun 2005 (UTC)

Ok, after reading this, "Update: the table schema conversions for en.wikipedia have been completed, remaining issues are currently being resolved by the developers. Some features may not work correctly (various page counts, for example) - this is normal." I have a question: when will EN Wikipedia be unlocked? Zscout370 01:52, 28 Jun 2005 (UTC)

It seems to have been unlocked about two hours before this note of mine. But the status page we are Talking about only said in Technicalese that the database had been converted, without a mention in English of the site being open to edits. (SEWilco 06:07, 28 Jun 2005 (UTC))

Bug on en: watchlist?

My watchlist on en now has this exact text:

<a href='http://en.wikipedia.org/w/index.php?title=Special:Watchlist&edit=yes'>display and edit the complete list</a>.

For some reason it's not converting the html into a link (although the url can be clicked on its own). --Brian0918 03:23, 28 Jun 2005 (UTC)

It also shows up in the text indicating that the article is too large:

This may be longer than is preferable; see <a href="/wiki/Wikipedia:Article_size">article size</a>.

User edit counter broken

The user edit counter at [1] doesn't work on upgraded wikis. — Bcat (talk | email) 20:10, 28 Jun 2005 (UTC)

Cool, a new version is up already! — Bcat (talk | email) 22:57, 28 Jun 2005 (UTC)

Upgrade/downgrade/foobar

RTFM, i know, i should have done that before...

i have to admit that i kept upgrading my wikis by simply copying and re"installing" it and modifying the LocalSettings.php all the time. It used to work always, but now i am stuck:

i upgraded from 1.4.4 to the latest version, which caused a weird mix of utf8 and latin-1 encoding within single pages. i dont see a real pattern, but well.

doing the upgrade1_5.php caused : [..]/var/www/wiki/maintenance# php upgrade1_5.php 2005-12-14 22:50:50: Page table already exists; aborting

trying to update to 1.4.12 causes this:

A database error has occurred Query: INSERT INTO `old` (old_namespace,old_title,old_text,old_comment,old_user,old_user_text,old_timestamp,inverse_timestamp) SELECT cur_namespace,cur_title,cur_text,cur_comment,cur_user,cur_user_text,cur_timestamp,99999999999999-cur_timestamp FROM `cur` WHERE cur_namespace='8' AND cur_title='1movedto2' Function: Article::quickEdit Error: 1146 Table 'wikidb.old' doesn't exist (localhost)

doing the update from the latest 1.5 works perfectly, but i have never ever been able to do the unicode conversion. :(

so there has been a backup of the table before the whole upgrade, but i have been gone for a bit (the upgrade was urgent and just had to be done as fast as possible) so the db has been used... i cannot use the old db anymore. but no one of us wants to use the mixed-encoding-pages :(

any ideas how to still get to be able to use 1.5 probably? (sorry for posting here, didnt find an email address) Chris