10: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--