28 Sep
2012
28 Sep
'12
7:07 p.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig442D3761E89E1257982D9DE5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/27/2012 02:06 PM, Dave Neary wrote: > Hi Karsten, >=20 > On 09/27/2012 12:09 AM, Karsten 'quaid' Wade wrote: >> Garrett's new MediaWiki skin is getting close to completion, and it >> happens to run on MediaWiki 1.19, which we need to upgrade to. >> >> We have a few approaches: >> >> 1. Staggered upgrade - update MediaWiki 1.19 (either with an RPM or >> ZIP), test, then update the theme. Do move to OpenShift as another >> process. >> >> 2. One rollover - create the new site with the new version and the new= >> theme on OpenShift, import the data (pages and users), test; then free= ze >> the old wiki, do a final import of pages and users, and roll over DNS = to >> the OpenShift instance. >> >> Advantages? Disadvantages? Different approaches? >=20 > It seems to me that we can cut things up into different bits, each of > which is independent. We can do some of the things independent of > getting the new site ready to go: >=20 > 1. Upgrade MediaWiki to 1.19.2 - this should be a noop for site visitor= s > and users It occurred to me that we could skip the upgrade to 1.19.2 for the current site. Can't we just migrate the data directly? There must be a process or tool for updating the database before moving to 1.19.2, so we i) copy the 1.16 data, ii) convert it to 1.19 data, iii) pull that in to the new site. Otherwise, I don't see the value in going through whatever will come up in the update of the current instance. > 2. Preparing the content of the site for the migration - we're replacin= g > ~15 pages managed by Wordpress by ~6 or 7 wiki pages - we need to make > sure all the links work, point at existing pages when it's appropriate,= > and we need to do the copy writing for Develop, Documentation and maybe= > review the contetn of Community (which is a bit wordy for my taste righ= t > now). >=20 > 3. Install extensions which we need for the new site - we need to > evaluate first. I'd like to have an RSS extension, perhaps a Calendar > extension, and one for embedding videos from YouTube >=20 > 4. Updating the content with some of the new content we have - videos > and screenshots a-go-go, the updated installation guides that Jason has= > created, gathering links of blog entries from RobertM and jbrooks (amon= g > others) on topics like integrating Gluster storage, etc. >=20 > 5. Installing the new theme >=20 > 6. Moving to new hosting - either OpenShift or alternate hosting when w= e > have it. I'm still in favor of using OpenShift. It reduces the number of services (and servers) that Infra manages. MediaWiki is a commodity service, so perfect for a PaaS; cf. Jenkins and Gerritt that are key to the development, so making those core services we manage makes more sense. Similarly, I'd like to move Mailman over to OpenShift; I think we're still waiting for some SMTP features. > I think we can do the MediaWiki upgrade and extension selection now and= > completely dissociate those from the new website deployment. > We definitely need to get to "feature parity" with the old site ASAP, > and I think we need to integrate some newer content too pre-launch. Yeah, I'd like to understand further why parity is necessary. > The new hosting, I think, can come afterwards. Are we ready to move to > OpenShift right now? I think we have 1.19 on OpenShift, so no, there are steps to get there. >> Garrett - we have our install at /wiki, which is a bit standard, and >> there are reasons AIUI: >> >> http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory >> >> Note the admonition that doing the wiki at root-level means no support= >> from Wikimedia developers. >> >> The idea to make the MediaWiki instance the entire site means we need = to >> decide how we want www.ovirt.org to resolve, same with wiki.ovirt.org,= >> and do we hack MediaWiki to make it work with / instead of /wiki. >=20 > which do you prefer - redirecting to /wiki, or using modrewrite to spoo= f > it? I think it would be prettier, but I am wary of deviating from the upstream way of doing things. Just using the EPEL RPM gets raised eyebrows, even though it no longer moves things around (using symlinks instead.) >> - Karsten, who wrote all this when about to check on the situation wit= h >> MediaWiki 1.19 in Fedora/EPEL, and realized we could skip the problem = by >> using OpenShift directly and immediately. >=20 > What is your position, in general, on using upstream releases from > .tar.gz? Do you think we should require an RPM? Package is superior. But there is no 1.19 RPM from Fedora or EPEL, and OpenShift can be thought of as another package format. > There's a little issue upgrading 1.16 to 1.19 you should be aware of - > $IP isn't set in the local config file any more, it's calculated at > runtime - and it didn't quite work with the way Fedora packaged the RPM= > previously (to simplify, MediaWiki expects to find the whole applicatio= n > in one directory hierarchy). >=20 > Anyway, I favour doing it step by step if we can. Sure, I think that makes sense. All-at-once rollover is more of a MO around if we upgrade the standing wiki or not. I think we'll want to take things in steps and stages, for sure. - Karsten --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enig442D3761E89E1257982D9DE5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQZfVa2ZIOBq0ODEERAovmAJ9ezKsK6PUs7b39nAHon4O8Y+W3IgCeIWss rWAHWP9BA2Y9hSkIbol2De0= =FuPk -----END PGP SIGNATURE----- --------------enig442D3761E89E1257982D9DE5--