10:28 a.m.
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--