This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5757A9B7B044898DED5F3BC9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/29/2012 05:03 AM, Dave Neary wrote:
Hi Karsten, =20 On 09/28/2012 09:07 PM, Karsten 'quaid' Wade wrote:
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 u= p in the update of the current instance. =20 It's even easier than that - you point a MediaWiki 1.19.2 install at a 1.16 database, and MediaWiki upgrades the database for you the first time you load it. There are also other resources that need to move, images & file uploads, themes and so on. But the database upgrade is trivial.
OK, great.
I'm still in favor of using OpenShift. It reduces the number of servic= es (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. =20 OK - so we should clarify what we're looking for with AlterWay - two servers, one for Gerrit and one for Jenkins, and that's it? Where will our git repositories live?
AIUI, Jenkins should be bare metal. Jenkins can be virtualized, but needs to be larger than a web server. We also should move Mailman and the httpd served directories (the yum repositories.) We've also been talking about a new service around the hooks and plugins, that needs a web host with some kind of application stack.
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. =20 Parity in the sense of fulfilling the same function as the former WordPress pages - providing news, download information, links to documentation and community resources - the "features" that are currently done in WordPress. =20 The reason I use feature partity is because Garrett's made it clear tha= t the move to MediaWiki is primarily to replace what the site does now - after that we will need to add extensions for things like embedding videos and screenshots, providing RSS feeds for news and events, including a calendar on the website, all the other cool stuff we want t= o add (like the extensions download page, better integration with Bugzill= a via the REST API, etc).
OK, I was reading parity as meaning, "we need to update the current MediaWiki before we move the site to the new instance." +1 to above.
The new hosting, I think, can come afterwards. Are we ready to move t= o OpenShift right now?
I think we have 1.19 on OpenShift, so no, there are steps to get there= =2E =20 I meant in terms of having the service available. Is there anything we need to do besides updating DNS and moving the database & files to the new server?
Garrett, anything here? We'll want to have testing steps in there so we can rollback, etc.
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. =20 I have no opposition to upgrading the standing wiki to 1.19 as a preparatory step - with the usual precautions (database back-up, don't over-write the old MW install before checking the new one works, etc). But if you need a package, then that is not practical. That is up to th= e infra team to decide.
OK. I'm not directly opposed to upgrading the standing wiki to 1.19, but I think it's an unnecessary step and additional risk and hassle we don't need. Sounds like the risk and hassle are more minor than I feared, but if we don't need this step, perhaps we can just skip it? - Karsten --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enig5757A9B7B044898DED5F3BC9 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/ iD8DBQFQaUYO2ZIOBq0ODEERArPmAKDkfFp6R/TtDrIrIOhRNhgglRN77gCeJnoU GYpYHWW7pgDkQ1dLHAoBc0w= =7rPt -----END PGP SIGNATURE----- --------------enig5757A9B7B044898DED5F3BC9--