[imc-sf-active] [imc-sfa-servers] maintaining popelin - the server hosting your imc

[Daniel P]

On Wed, Mar 2, 2011 at 3:38 PM, mark burdett <mark at indymedia.org> wrote:
> On Wed, 02 Mar 2011 14:07:42 +0100, kwadronaut wrote:
>> I suggest you also take a look at
>> http://lists.indymedia.org/pipermail/imc-sf-active/ for migration ideas.
>
> so when can we have the migration hackathon that dannyp suggested?
> i'm pretty flexible as long as we schedule it ahead of time.

I have similar flexibility.  I suggest we pick a few weekends,
starting no earlier than April.  I think we can break up the work into
4 distinct hackathons.  I split them up for manageability as well as
different skills that are required.  That being said, if we do one of
them and slam-dunk it, we can keep working if we're on a roll.

The first hackathon I say we write tools to wholesale convert an
sf-active database to a complete representation of the data that's
easily understood and parsed w/o knowledge of the sf-active schemas.
We test these tools on multiple sf-active IMCs to try to code for all
of them, not just some of them.

The second hackathon, we take the outputs from the previous hackathon
and write tools to import them into functioning modern CMSes, e.g.
drupal or wordpress.  We pick a target CMS -- I'd suggest drupal --
based on whatever is easiest for us to do.  If others want to use
other targets I'm cool with that, too - we probably all will have
similar issues and working at the same time should be good motivation
(plus competition can be fun).

The third hackathon - to be scheduled after the first two, so that we
can coordinate with the IMCs that would need to use the software -- we
use our tools to actually migrate over every IMC.  This involves
letting them know in advance what their options are and giving them a
choice, and telling them that if they do nothing we will migrate them
over to our reference target (e.g. drupal).  It sucks to kindof impose
this, but I think we'll be in a healthier position after, so we might
as well.  The third hackathon itself would actually be the work of
moving the IMCs over to their new platform(s).  Ideally we'll have
designers around who can make custom CSS and/or CMS templates for each
IMC, but in the absence, we'll just have a bunch of boring and
homogenous looking IMCs.

The fourth hackathon would be a couple of months after the third one,
where we would fix issues that the functioning IMCs have raised in the
months after they had been using their new sites for awhile.

The IMCs I'd like to bring to the table - note I haven't expressly
discussed this with all of them yet -- are (at least) Pittsburgh,
Puerto Rico, and Miami.  We also have Cleveland and some others, but I
believe they are so completely dead (not sure I have an active
contact) that we can probably just httrack their site to turn it into
static files, run the script produced in the second hackathon, and
archive the result in case someone wants it in the future.

Daniel