Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index

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
<> 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 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.


Benjamin Horst
646-464-2314 (Eastern)

E-mail to for instructions on how to unsubscribe
List archives are available at
All messages you send to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.