Re: [libreoffice-website] [SC] Decision about CMS

Hi Christian and Andrea,

On Oct 20, 2010, at 12:05 PM, Christian Lohmaier wrote:
> On Wed, Oct 20, 2010 at 1:26 PM, Andrea Pescetti
> <pescetti@openoffice.org> wrote:
> > Marc Paré wrote:
> >
> > A proper discussion would not fit the deadlines and tools the Document
> > Foundation has now: if a decision has to be taken now, it will miss the
> > bigger scope. If the Document Foundation must choose a tool that will be
> > flexible enough to rebuild all the current OpenOffice.org infrastructure
> > on it
>
> No. I strongly disagree. Not one tool that can do all.

I'm with Andrea here--I think reasonable consolidation of web assets will make for simpler 
administration (less effort over time), especially because upgrades will only have to be done to 
one core system. I also think it provides a better user experience via consistent design, domains 
and user accounts.

> > (e.g.: OOo site; Extensions; TCM; QATrack),
>
> And even that: Duplicating the extensions site would be a waste of
> time and efforts. There are already two repositories, the OOo one, the
> FSF one. It would be bad if there would be another one, just for the
> sake of having it.
> LO should be compatible to OOo in that regard, Extensions should run
> on OOo, LO, other derivates, thus a dedicated site is a nogo.

Extensions that work on OOo and LibO would be great, but I can't imagine that will be the case over 
the longterm. I think it would be very risky to rely on the existing OOo Extension repository to 
work for LibO for very long... but on the other hand, one repository with a parameter for each 
extension to indicate whether it works on OOo, LibO, or both, might be pretty useful.

> > then Drupal is that
> > tool; I can't imagine how to rebuild the Extensions site and all
> > processing in Silverstripe, for one.
>
> It would involve creating an appropriate module. But again, I'd not
> see that as a good idea.

If we're worried about finding enough admins for our CMS, this is just 10x more complex and we 
should be even more cautious to avoid the situation.

> The extensions site has a different target user group, and a different
> contributers group, so I don't see any reason to try to cover it with
> the same tool that is used for the website.
>
> > 2) Moving to a database-based CMS can imply loss of traceability of
> > changes. The current CVS infrastructure, as bad as it can be, allows to
> > see a full log of changes very easily. Drupal has a killer feature here:
> > site settings can be exported to PHP code, shared among a distributed
> > development team through any revision control system (SVN, git,
> > whatever) and applied in a safe way to the running site. It is very
> > important that we are able to answer the question "Who enabled
> > this permission, when and why?"
>
> Why is that a killer feature of drupal, why do you assume you can't
> put silverstripe's configuration under version control?
> What makes you think silverstripe wouldn't have a change history for the pages?

Most CMSs store configuration information in their databases and do not keep a record of config 
changes made in the web admin (for things outside of the content themselves). This is a killer 
feature because Drupal offers a way to track those changes as well. It's not the pages we're 
talking about here at all. If SilverStripe has something like this, I have not seen it.

-Ben

Benjamin Horst
bhorst@mac.com
646-464-2314 (Eastern)
www.solidoffice.com


--
E-mail to website+help@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/website/
All messages you send to this list will be publicly archived and cannot be deleted