[website-dev] notes on kenai migration, WAS: Re: [website-dev] When Does the Redesign Begin?

Lars Nooden wrote:
> On 06/28/2010 12:08 PM, Bernd Eilers wrote:
>> A staging site for OOo on kenai is going to be set up soon but I can
>> not give any information on how soon that will be at the momment.
> 
> 1) Please give more consideration to the methods or tools I describe
> below.  They might successfully obviate the need (or perceived need) for
> the burden of creating or using a CMS.
> 
> 2) If you are going to re-invent the wheel, please be sure to re-invent
> a better wheel, not just a newer one or a different one.  ;)
> 
> On 06/28/2010 12:08 PM, Bernd Eilers wrote:
>> You can learn more about kenai migration at 
>> http://kenai.com/projects/ooo-migration/pages/Home
> 
> 	"The move is going to include services like publishing
> 	of web content, mailing lists, bugtracking, ... and the
> 	existing content of those."
> 
> Ok.  From a software engineering, maintenance and security perspective a
> monolith should be avoided.  So if you are making a framework into which
> many modules fit, then great.  If it is yet another BlackBoard(tm), then
> please stop and erase the disks now.  ;)
> 
> The technical side of publishing web content can be done here and now
> using CVS plus a few templates using CSS and SSI. 

Surley everyone uses CSS nowadays and this will surely stay the same 
with the new website.

There a dozens of webframeworks and technics to "decorate" webpages with 
header footer and standard navigation elements used out there. SSI maybe 
just one of the simpler and older things. There´s surly much more 
dynamic things on a website like OOo than what can be achieved by using SSI.

Kenai uses ruby on rails. (http://rubyonrails.org/). Collabnet uses java 
servlets.

For the Source Code Managment System used to store the website content 
the plan is to move from CVS to SubVersion with the Kenai Migration.

Note that I am not saying we can´t start to experiment with a new look 
and feel using prototypes which are just based on CVS, CSS, SSI etc. My 
concern though is that if we really would switch to a new look and feel 
which could be considered a major redesign and not just small adaption 
to new branding before the kenai migration most of the work put so far 
into providing the CURRENT look&feel on the kenai infrastructure would 
well have been done for the trash :-(

> The templates, if
> they are just a port of the current OOo Look & Feel, can be done in a
> few weeks -- even allowing for tremendous time padding for meetings and
> phone tag.
> 

 From what I have done so far I have experienced quite a lot items where 
the current OOo stylesheets had some definitions which did interfere 
with kenai webpages in a way that it destroyed their look which had to 
be resolved by explicitly overriding too broad implicit CSS definitions 
of the OOo stylesheet on a kenai theme page.

Creating a general method for "decorating" the normal OOo webpages is 
maybe the simpler part where more work is involved is to resolve CSS 
Conflicts when mixing OOo CSS and kenai CSS on kenai provided web 
content, like eg. the dynmacally generated list of projects or the also 
dynamically generated list of mailinglists on a project etc.

You may note that even the current website does already dynamically add 
header footer, navigational elements and CSS to webpages stored in the CVS.

> The mailing list can be managed by GNU Mailman.  Tweaking that to match
> the current OOo Look & Feel can be done in a few hours.  

Kenai uses sympa (http://www.sympa.org) for mailing lists which is also 
a mailing list manager under GNU General Public License and may have 
some advantages and disadvantages when compared to GNU Mailman. I am not 
much into details on both of those mailing list managers so can really 
compare them.

> The phase out
> of the old list manager can be done starting one list at a time, growing
> to several at a time, over a few weeks, mostly by fiddling with DNS MX
> entries.
> 

The current idea is to initially get mbox files from collabnet migrate 
them to sympas mailing list archive files and than incrementally upgrade 
those by grabbing new content from the collabnet website frontend to the 
mailing list archive.


> The bug tracking can be managed by any ticketing system: RT, Bugzilla,
> OTRS, Trac or Redmine.  Tweaking that to match the current OOo Look &
> Feel can be done in a few hours.

The plan is to switch to bugzilla. On the kenai infrastructure bugzilla 
and Jira are the two options for bugtracking. If you think you can 
really tweak bugzilla in a few hours you are welcome to help doing that 
task ;-) altough I would think it will need some more effort.


> 
> Judicious use of vhosts, links, and stylesheets can provide a unified
> appearance and the user will experience the whole as a single interface.
> 

Stuff like vhosts etc. will be migrated and be very simililar to what we 
are doing now. There will have to be at least a day outage or so to 
switch DNS entries from Collabnet to Oracle of course.

> Migrating the old archives from the old bug tracker and the old mailing
> lists, can be done over time after the roll out of the new systems.

We will get database dumps of the issuezilla database from collabnet. 
Bugzilla is based on issuezilla and we can create migration scripts to 
transform an issuezilla database into a bugzilla database. For mailing 
list archives we can get mbox files from collabnet and migrate those to 
what sympa uses and than incrementally update that to more recent 
messages on those mailinglists via website content grabbing.

> Just lock them read-only and leave them running until the data is
> successfully copied and transformed.

We can also consider incremental upgrades via website content grabbing 
after an initial migration of such a database to minimize the time 
needed to have the bucktracking system read-only. Same as with the 
mailing lists archives.

> 
> /Lars
> 
> 

Kind regards,
Bernd Eilers