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 > <[email protected]> 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 [email protected] 646-464-2314 (Eastern) www.solidoffice.com -- E-mail to [email protected] 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
