Closed Bug 707181 Opened 13 years ago Closed 11 years ago

Update wiki.mo to Mediawiki latest stable

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task, P4)

All
Other

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ashish, Assigned: jd)

References

Details

(Whiteboard: [triaged 20120831][waiting][dev resources])

Attachments

(1 file, 1 obsolete file)

Barely been 3 days since Bug 671357 closed and we have a newer version of mediawiki - 1.18
Assignee: server-ops → nmaul
Adding CC's. This will happen once we've gotten the kinks worked out of the recent Mediawiki 1.17 deployment.

The CC's added here are the main people who had problems with the last upgrade. We do not have a formalized QA team or procedure for wiki's, so to an extent we have to rely on informal testing to know if a change is better or worse. There's an open bug to improve this, but a lot of work still needs to happen to formalize exactly what should be tested. The basics (login, logout, view page, edit page) are clearly not sufficient for some folks.

In the meantime, since you (Deb / Pierros) seem to have the best handle on how well things are or are not working, you're the best we've got for testing.


For the record, I don't think 1.18 will be as headache-inducing as 1.17 was. The changes I see seem to have a smaller impact on skins and extensions. We'll have a better idea once we get it into staging.
Attached file wikimo skin for 1.18 (obsolete) —
The 1.19 tarball is about to be released, but here is the skin for wikimo so it works with 1.18.  I'll test it against 1.19, but it should work.
I should note that this skin is made to be un-tarred right in the top of the mediawiki installation and default skin needs to be set to "wikimo" inside of LocalSettings.php.
We'll need a reviewer(I can do it), a QA(deb and pierros, I guess) and security review.

Jake,

When do you think it would be safe to experiment with wiki.allizom.org?
(I do have a git repo based on the svn repo if you want it...)
I'll take this as I've been herding wikimo lately
Assignee: nmaul → bburton
:Milos and Mark, depending on SCL3 move things, I can look at upgrading -dev wiki-dev.allizom.org to 1.18, as prod is still currently 1.17.1, sometime next week and then we can try the new skin.

Mark, were you going to do the committer stuff or do you just want to submit patches via Bugzilla?
Status: NEW → ASSIGNED
I don't want to widen the scope of this *too* much, but perhaps it would be worthwhile for us to start tracking our own "extensions" dir as well as skins-mozilla. Right now those things are non-tracked files that live on the admin node + web nodes. It hasn't been a big deal because we haven't really done any significant custom dev work in /extensions/, but since this skin does have some things there... might be time to look into that.
Status: ASSIGNED → NEW
(In reply to Brandon Burton [:solarce] from comment #7)
> :Milos and Mark, depending on SCL3 move things, I can look at upgrading -dev
> wiki-dev.allizom.org to 1.18, as prod is still currently 1.17.1, sometime
> next week and then we can try the new skin.

Brandon,

There's some stuff to do before doing that. Upgrading mediawiki would mean our current skin wouldn't work and I prefer us having a working skin and deploying it to -dev- in the upgrade process.
 
That said, we'll need a code review and security review before we start upgrading MediaWiki software.

Also, let's forget about doing everything in one bug, and file bugs for each step in the process. We could make this tracking bug for release, and then file bugs for enabling dev, code review and secreview. Once all the dependencies are RESOLVED, we can go with QA and deploy it on -prod-.

Jake, +1.
Attached file wikimo skin for 1.18
fixed a bunch or problems.  Note that the right way to use this is to extract the tar file in you MW installation dir.  It won't work with MW 1.18.0 but does with 1.18.2 because of a bug that was fixed in .0.

The following two lines have to be added to the LocalSettings.php file:

  $wgDefaultSkin = "gmo";
  require ( "$IP/extensions/gmo/gmo.php" );
Attachment #616235 - Attachment is obsolete: true
(In reply to Jake Maul [:jakem] from comment #8)
> perhaps it would be
> worthwhile for us to start tracking our own "extensions" dir as well as
> skins-mozilla.

Please have a look at http://noc.wikimedia.org/conf/ for an example of how to publish LocalSettings.php and other config info without giving away any sensitive secrets (passwords and the like).
Whiteboard: [post SCL3]
Whiteboard: [post SCL3] → [review on 6/25]
Renormalizing priority levels... P4 is "normal" now.
Assignee: bburton → server-ops-webops
Priority: -- → P4
Summary: Update wiki.mo to Mediawiki 1.18 → Update wiki.mo to Mediawiki latest stable
Whiteboard: [review on 6/25] → [triaged 20120831][waiting][dev resources]
Blocks: 738257
need to figure out what to do to move this forward.  I'm testing on 1.19 this weekend.
Email from Brandon today where we tentatively set up meeting about wikimo for the beginning of December (in two weeks).
Assignee: server-ops-webops → jcrowe
QA Contact: cshields → nmaul
FWIW, Web QA has a few tests for Wiki [1] (and we're always adding more as we have time); is there any way we can get our Selenium nodes' IPs white-listed and auth decoupled for them, so we can run our tests against them, without auth?

[1] https://github.com/mozilla/wiki-tests
[2] http://qa-selenium.mv.mozilla.com:8080/view/Wiki/
In addition to Web QA's tests, ckoehler suggests the following manual testing:

1) login (https://wiki-dev.allizom.org)
2) edit using regular and rich text editors (though nonfunctionality of the latter should probably not be a showstopper: https://bugzilla.mozilla.org/show_bug.cgi?id=738257)
3) try all the plugins: https://wiki-dev.allizom.org/Special:Version#Installed_extensions
(In reply to Justin Crawford [:hoosteeno] from comment #17)
> In addition to Web QA's tests, ckoehler suggests the following manual
> testing:

<snip>

Just to be clear, we can't run our tests until someone from IT decouples auth from either wiki-dev.allizom.org and/or wiki.allizom.org, and ensures that the latest code is running there.
I disabled auth on dev for now

wiki-dev.allizom.org
Quick manual test update. 

Things seem to be working, in general. I could login, go to pages, edit them, search. A couple issues to note:

* I got "Service unavailable" lots, especially when doing a big query like https://wiki-dev.allizom.org/Special:ListFiles
* I was using the above link to see if uploads work. I was not able to validate this. It's not clear whether file uploads are working.

I did my best to exercise these extensions with these results:

* semantic forms appears to work
* bugzilla works
* smartsheet not installed (bug opened)
* watchlist not working exactly right (bug opened)
* wikieditor not linked in gmo (suspect this is on purpose)
* createbox works
* labeled section transclusion works
* notitle works
* semantic html works
* syntax highlighter works
* urlgetparameters works

Many of my very simple tests are on this page: https://wiki-dev.allizom.org/Extension_Test_Page

I ran out of time for testing other extensions. Several didn't have an obvious test path for a regular wiki user. HTH!
Depends on: 838391
No longer depends on: 838383
The stage site has been upgraded. I pulled a fresh copy of the database from prod before the upgrade so the data is (reasonably) current.

Please file bugs if you find any issues, otherwise I will be upgrading the prod site in short order.
Depends on: 843360
Stage and dev have been refreshed from prod. It is time once again to do some testing. We will schedule the prod upgrade this coming week if no further issues are discovered.
Prod is upgraded. Let webops know if you find any major issues.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 856021
Depends on: 876678
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: