Re: [Fwd: eZ and Drupal to be dismissed]

["Lee Tambiah" <l_tambiah linuxmail org>]

Fair enough, after playing with Drupal yesterday, I have also came to the same decisions as yourself, it's either PLONE or MidGuard. It seems you and Henri have addressed most points regarding Midgard. Also Ramon has added many points also, so we are all most there. Would you like me to cut down the CMS requirements Wiki Page down to PLONE and Midguard now?

Lee

> ----- Original Message -----
> From: "Quim Gil" <qgil desdeamericaconamor org>
> To: "gnome web" <gnome-web-list gnome org>
> Subject: [Fwd: eZ and Drupal to be dismissed]
> Date: Fri, 27 Oct 2006 00:53:13 +0200
> 
> 
> Update on my previous request: eZ and Drupal are being dismissed,
> opinions from a sysadmin point of view are now even more needed about
> Midgard and Plone.
> 
> From: Quim Gil <qgil desdeamericaconamor org>
> To: marketing list <marketing-list gnome org>
> Subject: eZ and Drupal to be dismissed
> Date: Fri, 27 Oct 2006 00:48:53 +0200
> 
> 
> eZ and Drupal are the following candidates to be dismissed. I'm putting
> them in a same row because they have complementary problems and virtues
> from the wgo revamp perspective. eZ could be perhaps an appropriate tool
> for wgo but we lack human resources. Drupal is backed by many potential
> volunteers, but I think that making this tool matching the wgo
> requirements (specially i18n) would be pretty complex.
> 
> For these reasons I think the final will be decided between Midgard and
> Plone.
> 
> More in detail (DRUPAL FANS PLEASE READ UNTIL THE END)
> 
> About eZ Publish:
> 
> - Localization: many requirements are covered and I believe that someone
> with good PHP skills and a lot of free time could create the missing
> functionality at some point. Native XML content, CVS & diff and a lot of
> code and thought already implemented in a tool that has been
> multilingual since the beginning. See
> http://ez.no/community/developer/specs/improved_multi_language_in_ez_publish_rev_2
> 
> - Look&Feel: probably no problem.
> 
> - Learning curve: apparently eZ is easy to install, setup and use, and
> there is good documentation around. I'm not sure about the complexity of
> customizing the tool and making it work as we wish. The problem here is
> that most of the potential volunteers around would start from scratch.
> But well, this would be a positive point as well.
> 
> - Security and upgrades: typical scenario of a decent coverage. Patches
> and maintenance releases are published as soon as a vulnerability is
> detected and the upgrading is done via scripts and requires some
> tweaking.
> 
> - User management: provides what we need.
> 
> - Contributors around: I'm really concerned about who would be willing
> to work on this, and learn to an advanced level to be a reliable
> webmaster. Michael Maclean has been really helpful and I'm sure he would
> assist us in the process. Same thing with the people from Igalia. But I
> don't see many people using this CMS around and I wonder how cooperative
> the PHP-friendly division would be considering that most of them are
> playing around Drupal, and are happy with it. If we are having serious
> trouble finding contributors for more broad tasks like wgo planning,
> writing texts etc... please understand if as a coordinator of the wgo
> revamp I fear we won't find enough resources to work well and fast on
> the wgo CMS implementation. In this release and in the following.
> 
> The latter is the heaviest reason to dismiss eZ, since I see more
> probabilities of ending up with a real website in place and decently
> maintained via Drupal, Midgard or Plone. In other circumstances I think
> it is a good CMS, and if we were a professional web development agency
> with a budget I would seriously reconsider this option.
> 
> 
> About Drupal:
> 
> - Localization: although the i18n module has done a lot of progress,
> it's still miles away from our requirements. If wgo would be just in one
> language I would probably bet on Drupal (as I have done consistently in
> the past). But thinking in a scenario of wgo translated into +20
> languages in one year I see a lot of risk around Drupal. Either we would
> need to develop a lot of hacks and additional features or either we
> should design a fragile workflow a) not convincing the i18n team and/or
> b) with a high probability of ending up in a low quality mess and a lot
> of improductive work. Drupal is conscious of its weakness in the
> multilingual field and they are putting slowly a remedy (see the recent
> thread at http://drupal.org/node/88417 ) but this process will take long
> and we need a multilingual wgo before.
> 
> - Look&Feel. We would get what we want.
> 
> - Learning curve. It's easy to get from 0 to an editor level. It's not
> difficult to get from intermediate admin/hacker level to advanced. It
> would be appropriated to our needs, I think.
> 
> - Security and upgrades. Vulnerabilities are quickly found and generally
> quickly fixes with maintenance releases. The upgrades are made with
> scripts and currently it's a quite straightforward process. There are
> not big problems with the core CMS, but the maintenance of the
> contributed modules is another story (i.e. the diff module was abandoned
> by the maintainers and now we would need to port it ourselves in order
> to use it in the last versions, these kind of stories are not that
> rare).
> 
> - User management. Permission levels are more fine grained than before
> and there is an LDAP feature. It would do the work although I believe
> other candidates are much more stronger in this field. But well, we
> don't expect to have complex permissions policies in wgo either. It
> would probably do the job.
> 
> - Contributors around. Definitely the best asset. Over the past months
> many Drupal fans got interested in GNOME, and/or the other way round.
> Many GNOME related sites are using Drupal and there is some expertise
> around. However, we have also experienced difficulties getting real
> commitment in our Drupal sites when we have needed them and I have to
> say that the level of complexity of these websites is not extremely high
> either. These are two reasons that make me think that although we might
> have many potential volunteers around, at the end I'm not sure if we
> would find the resources needed to hack a Drupal installation to the
> levels we want to achieve.
> 
> 
> This is why I think Drupal is another candidate to be dismissed for
> wgo... while keeping thinking that is a very good option for GNOME
> subsites without complex i18n requirements i.e. guadec.org,
> gnomedesktop.org and the many GNOME groups that are using it.
> 
> For this reason I ask to the Drupal webmasters and hackers with GNOME
> love to stay with us, subscribe to
> http://mail.gnome.org/mailman/listinfo/gnome-web-list and give a hand
> with the current installations - they need it. For instance, precisely
> these days Thomas Wood (GUADEC 2007 coordinator) is crying for Drupal
> help. See
> http://mail.gnome.org/archives/guadec-list/2006-October/msg00000.html
> 
> --
> Quim Gil /// http://desdeamericaconamor.org
> << signature.asc >>
> 
> --
> marketing-list mailing list
> marketing-list gnome org
> http://mail.gnome.org/mailman/listinfo/marketing-list
> << signature.asc >>
> 
> _______________________________________________
> gnome-web-list mailing list
> gnome-web-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-web-list

>



Regards

L. Tambiah

GNU/Linux Enthusiast

/**************************
 * "Having the source code 
 * means that we are not 
 * held hostage by anyone's 
 * support department." 
 *              --R. Nelson.
 **************************/


-- 
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze