Clicking on reply results in a forever spinning spinner, console shows a request to http://bits.wikimedia.org/skins-1.18/common/edit.js ending in 404.
Version: unspecified
Severity: normal
Description
Description
Details
Details
- Reference
- bz31087
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T31068 MediaWiki bugs to be fixed for 1.18wmf1 deployment (tracking) | |||
| Resolved | Reedy | T33087 Deploy LQT (1.18 Branch) on 1.18 LQT wikis |
Event Timeline
Comment Actions
edit.js was killed in r91750
Aaron removed the the REL1_18 version of LQT for being "broken", then has brought in the version from 1.17wmf1, which is broken cause of a lack of dependancies
Comment Actions
Well the 1.18 version needed a schema change, has anyone looked into doing this on the cluster?
Comment Actions
(In reply to comment #2)
Well the 1.18 version needed a schema change, has anyone looked into doing this
on the cluster?
I'll see what's needed now, and then look at scheduling the changes with Asher
Comment Actions
I've also got a feeling that the version in 1.18wmf1 is now a version from 1.16wmf4
In r97086 I moved it from a 1.16wmf4 special to using REL1_18 directly..
Looking at the schema changes, there is nothing since September 2010, which is well before the 1.17 branchpoint
Comment Actions
I'm marking this as a blocker for bug 29068 since there is at least one other wiki (ptwikibooks) where this bug will likely happen when the code is deployed.
(or there is a better tracking bug for this?)
Comment Actions
(In reply to comment #6)
(or there is a better tracking bug for this?)
That one worksforme :)
Comment Actions
unFIXING this... because its not fixed.
we want somewhat up to date LQT, and binasher is running the schema changes atm to allow this.
Comment Actions
I've forward-ported a bunch of changes I was making on another site, done a code review, and generally tried to get the code into a reasonable state. Some brief testing and it seems to work, I'd like it if folks could bang on it on the 1.18 cluster once the trunk state is deployed and let me know how it looks now.
My apologies for the mess of the current trunk state. Hopefully we'll have something nicer to deploy next time around :)
Comment Actions
Is there any actual bug in the version that's deployed? Reply works for me now. If there isn't, then the severity should be downgraded.
Comment Actions
(In reply to comment #11)
Is there any actual bug in the version that's deployed? Reply works for me now.
If there isn't, then the severity should be downgraded.
Right now there is a symlink to handle the edit.js dependency. I'm not aware of anything still broken.
Comment Actions
Sam and I planned out a deployment window for 20 hours from now (Wednesday, September 28, 20:00-21:00 UTC (1pm-2pm PDT)). Since Andrew has fixed up LQT on the trunk, this seemed like a sensible strategy.
If things aren't really broken, and assuming LQT in trunk isn't fully reviewed (I haven't checked that, so I'm guessing it isn't), then maybe we should call this off. That's not to say we couldn't deploy an update at some other point, but if things are at least nominally working, then it doesn't make sense to rush out a new version which could easily break other things.