It's time to try this upgrade again. Let's put a copy of our current MDC onto developer-staging and upgrade it to the latest MediaWiki. We'll need to use a copy of our database, since the database format has changed. Anyone recall what went wrong last time, so we can avoid that this time around? We need to get this upgrade done as it's holding up a number of other MDC related projects; I'm going to file bugs on those as appropriate, as being blocked by this, for future reference.
Last time we had an unknown bug which corrupted the database. Currently we are running mediawiki 1.5.6 with a modified code base. This project needs someone who can spend a lot of time going through the code and getting it back inline with mainstream. Any takers?
Wil or Mike would this be a good project for any of our summer interns?
What's modified in our codebase? I was under the impression we were running a stock MediaWiki with a custom skin and a couple of custom extensions. My goal is to be using a stock MediaWiki using only commonly-used extensions (the ones I'm proposing we install are so popularly used that they stay in lock-step with MW updates).
Moving these two bugs into Server Operations: Projects as it is more of a project.
Component: Server Operations → Server Operations: Projects
Sounds fun! If you can't find anybody else, I can always help.
It might be worth it to move this over svn, starting with a fresh copy of mediawiki, while we are at it. (In reply to comment #3) > What's modified in our codebase? I was under the impression we were running a > stock MediaWiki with a custom skin and a couple of custom extensions. My goal > is to be using a stock MediaWiki using only commonly-used extensions (the ones > I'm proposing we install are so popularly used that they stay in lock-step with > MW updates). > I wish that was the case, but unfortunately, I'm guessing years ago, the main code base was modified and then new versions merged on top of that creating somewhat of a mess. I couldn't tell you exactly what was modified, but I do know there are modifications. I guess we could do a diff against our version and stock 1.5.6.
That sounds like a good idea. If we're lucky, our customizations are moot in the modern MW versions. I'm really hoping we can get to a place where we can use a stock MediaWiki, but if we can't, then we definitely should move it into svn and start with a fresh copy and do our mods from scratch.
Yeah, I was hoping to keep it stock, but under svn just for extensions and deployment ease.
Who, if anyone, works on the MDC backend right now? We should probably CC them on this bug.
There's nobody that I know of working on MDC backend right now. Sancus in theory is available to help with that work but is pretty busy with remora right now. I'm willing to do the comparison of the MW 1.5.6 stock to our own install to see what we did to it though. I certainly know PHP well enough to figure out if we can get by with a stock install, and this MW upgrade is my #1 priority for my Q1 goals.
If someone can tell me where to look to find our current install's MW code, I'll do a diff against the official 1.5.6 distribution so we can start figuring out how to proceed.
(In reply to comment #11) > If someone can tell me where to look to find our current install's MW code, > I'll do a diff against the official 1.5.6 distribution so we can start figuring > out how to proceed. I'm pretty sure this will get you a copy of it: cvs -d:pserver:firstname.lastname@example.org:/cvsroot co devmowiki
That times out every time for me. Anybody know either what's wrong or what the right cvs checkout is? I poked around on MDC and couldn't find anything.
(In reply to comment #13) > That times out every time for me. Anybody know either what's wrong or what the > right cvs checkout is? Er, sorry. I never use anonymous anymore... Try this: cvs -d:pserver:email@example.com:/www co devmowiki
I've run a comparison of the standard MW 1.5.6 and our version, and our customizations are almost all minor (and even the big one, shared signon across all our languages, is not a very large change). If someone can do the base install of MW 1.9.3 or whatever's current onto staging and migrate the databases over, I'll see which patches are necessary and apply the ones that are. Several appear to be obsoleted by newer versions of the MW software, so we may not need many of them at all. If the new setup goes into svn, that's great, just will need to know how to fetch it so I can work with it.
It occurs to me that I don't actually know if developer-staging is the place you guys would like most to put this. It doesn't actually matter to me where it goes. :)
I'll find a place to put this. It is going to be a bit difficult because most of our boxes have php4 where this will need php5.
Yeah, that's what occurred to me. Is there a plan in place for PHP5 when we deploy MW 1.9.x for real on devmo?
Yeah, when we are ready to go live with it I can just upgrade giles. I bet if I upgraded to php5 right now it wouldn't break anything, but that is a bit scary.
Today I have been working on testing/porting the extensions to work with mediawiki 1.9.3. One problem I noticed is we have an rss extension that uses the magpierss library. It looks like this library is not compatible with php5.
After testing it seems to work despite not mentioning compatibility.
What extensions are you working on getting running? We're not planning to use our current breadcrumbs extension, so you can ignore that one.
Right now I have all of them working, but I can take that one out if you want me to.
Wow, I'm impressed. We thought that thing was a lost cause. Where can I access it? The URLs I think ought to work don't.
Right now I'm doing the porting on my laptop, but I'm going to set it up publicly today.
Sweet, I'll keep my eyes on this bug for word of that then. Thanks!
Ok, new copy has been installed at http://developer-stage.mozilla.org
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Any suggestions for approaches to testing to ensure this works fully, so we can be sure we don't have a repeat of what happened last time we did this update?
I actually don't remember what happened last time, but I would think just going through and using it would be the best way to test.
Oh, where can I go to check out a copy of this stuff so I can do some looking it over and see about fixing a couple of issues here and there?
The source is now in public svn and can be viewed at http://viewvc.svn.mozilla.org/vc/projects/developer.mozilla.org/trunk/
I think you can check it out with svn co http://svn.mozilla.org/projects/developer.mozilla.org/trunk/
I'd like to be able to check in some changes to test some fixes, but get this when I do svn ci: subversion/libsvn_client/commit.c:873: (apr_err=13) svn: Commit failed (details follow): subversion/libsvn_ra_dav/util.c:389: (apr_err=13) svn: Can't create directory '/repo/svn/svn/mozilla/db/transactions/2607-1.txn': Permission denied subversion/clients/cmdline/util.c:407: (apr_err=13) svn: Your commit message was left in a temporary file: subversion/clients/cmdline/util.c:407: (apr_err=13) svn: '/Users/sheppy/projects/mdc-new/trunk/svn-commit.tmp'
I can give you commit access to the repository. Have you used mozilla's SVN repository before and have you filled out the CVS contributor form?
I've checked out from the svn before, but never in. I've not done the CVS contributor form but will look for it and fill it out now.
I've filed the contributor form and the corresponding bug.
Question: once I check in a change to the svn repository, what steps need to be taken to make it show up on developer-stage so that I can test the change?
I'll just set it up to automatically svn up every 10 min or so.
Fantastic. Thank you!
Should be updating now.
For now it is probably fine to just comment on this bug. I looked at the problem and nothing is immediately obvious to me, but maybe the theme is using deprecated functions or something.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.