Install copy of MDC on developer-staging with MediaWiki 1.9

RESOLVED FIXED

Status

mozilla.org Graveyard
Server Operations: Projects
RESOLVED FIXED
10 years ago
2 years ago

People

(Reporter: sheppy, Assigned: oremj)

Tracking

Details

(Reporter)

Description

10 years ago
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.
OS: Other → All
(Reporter)

Updated

10 years ago
Blocks: 373238
(Assignee)

Comment 1

10 years ago
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?
(Assignee)

Comment 2

10 years ago
Wil or Mike would this be a good project for any of our summer interns?
(Reporter)

Comment 3

10 years ago
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).
(Assignee)

Comment 4

10 years ago
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.
(Assignee)

Comment 6

10 years ago
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.

(Reporter)

Comment 7

10 years ago
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.
(Assignee)

Comment 8

10 years ago
Yeah, I was hoping to keep it stock, but under svn just for extensions and deployment ease.
(Assignee)

Comment 9

10 years ago
Who, if anyone, works on the MDC backend right now?  We should probably CC them on this bug.
(Reporter)

Comment 10

10 years ago
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.
(Assignee)

Updated

10 years ago
Assignee: server-ops → oremj
(Reporter)

Comment 11

10 years ago
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:anonymous@cvs-www.mozilla.org:/cvsroot co devmowiki
(Reporter)

Comment 13

10 years ago
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:anonymous@cvs-mirror.mozilla.org:/www co devmowiki
(Reporter)

Comment 15

10 years ago
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.
(Reporter)

Comment 16

10 years ago
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. :)
(Assignee)

Comment 17

10 years ago
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.
(Reporter)

Comment 18

10 years ago
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?
(Assignee)

Comment 19

10 years ago
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.
(Assignee)

Comment 20

10 years ago
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.
(Assignee)

Comment 21

10 years ago
After testing it seems to work despite not mentioning compatibility.
(Reporter)

Comment 22

10 years ago
What extensions are you working on getting running?  We're not planning to use our current breadcrumbs extension, so you can ignore that one.
(Assignee)

Comment 23

10 years ago
Right now I have all of them working, but I can take that one out if you want me to.
(Reporter)

Comment 24

10 years ago
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.
(Assignee)

Comment 25

10 years ago
Right now I'm doing the porting on my laptop, but I'm going to set it up publicly today.
(Reporter)

Comment 26

10 years ago
Sweet, I'll keep my eyes on this bug for word of that then.  Thanks!
(Assignee)

Comment 27

10 years ago
Ok, new copy has been installed at http://developer-stage.mozilla.org
(Assignee)

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 28

10 years ago
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?
(Assignee)

Comment 29

10 years ago
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.
(Reporter)

Comment 30

10 years ago
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?
(Assignee)

Comment 31

10 years ago
The source is now in public svn and can be viewed at http://viewvc.svn.mozilla.org/vc/projects/developer.mozilla.org/trunk/
(Assignee)

Comment 32

10 years ago
I think you can check it out with svn co http://svn.mozilla.org/projects/developer.mozilla.org/trunk/
(Reporter)

Comment 33

10 years ago
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'
(Assignee)

Comment 34

10 years ago
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?
(Reporter)

Comment 35

10 years ago
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.
(Reporter)

Comment 36

10 years ago
I've filed the contributor form and the corresponding bug.
(Reporter)

Comment 37

10 years ago
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?
(Assignee)

Comment 38

10 years ago
I'll just set it up to automatically svn up every 10 min or so.
(Reporter)

Comment 39

10 years ago
Fantastic.  Thank you!
(Assignee)

Comment 40

10 years ago
Should be updating now.
(Reporter)

Comment 41

10 years ago
Looks like the JavaScript stuff in the developer-stage version of the wiki doesn't run; there's no toolbar when editing and the semi-ajaxy stuff that it tries to do in the preferences isn't working.  Could you give that a quick check for me?

Should I be filing separate bugs for little stuff like this?  It's related but starting to diverge from the basic concept a little too.
(Assignee)

Comment 42

10 years ago
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.