Another issue that we have to double check for any ready CMS system is the security. I'm not stating that Drupal is insecure or have such a bad history. But we have to bear in mind that any common CMS or Wiki application might have some security problems in future which might be problem for us as script kiddies would easily exploit the system. For that reason, we have to check the sources, and if necessary make some GNOME specific changes in all input/login processes. This way we might prevent some security problems to affect wgo/go before Drupal (or any CMS application chosen) team releases patch for them. I can put my work force after choosing CMS system to see if it's secure enough, and will try to make necessary fixes as much as my skills allow. On Sat, 2006-07-08 at 00:58 +0200, Quim Gil wrote: > On Fri, 2006-07-07 at 12:25 -0300, Guilherme de S. Pastore wrote: > > > However, I've already seen and faced all kinds of problems with drupal, > > from security to upgradability issues > > Could you be more specific about these problems? The ones I remember > were not caused directly by Drupal but by > > a) lack of sysadmin resources or skills within the members of the GUADEC > team with the permissions needed. > > b) GNOME permission policies having to satisfy the security of several > tools, services, priorities and servers. > > c) outdated versions of several packages affecting the functioning of > Drupal. > > d) lack of coordination between the GUADEC team and the Sysadmin team. > > We also tried an upgrade of a production site when Drupal 4.7 was still > beta and without testing first on a development server. It didn't work: > our fault. I bet now that 4.7 is more than stable the upgrade would be a > child's game. > > I might be missing problems, please detail those that were caused by the > Drupal code, not by we humans. > > > , which IMHO do not make it the > > best option to set the infrastructure of a website we want to keep > > around for long on. > > Not having names for better alternatives doesn't help, as Jeff has > pointed. :) > > You opinion as GNOME sysadmin is very important. Please make a list of > requirements the tool(s) to be used should match and we will make sure > the CMS(s) selected accomplish them. > > > > And I did not make it clearer because I've already exposed this concern > > to qgil in the process of setting up drupal for guadec.org. > > As said, I don't think the problems were caused by Drupal but about the > GNOME/GUADEC human context and the server infrastructure. > > However, many have pointed that one of the keys of the GUADEC 2006 > success was the website. With all the problems we have got, the result > seems to be much more satisfactory than the results obtained with the > current wgo platform. > > > About Drupal vs MediaWiki vs etc, there is not much point discussing > tools before agreeing requirements. By July 17th Greg Nagy needs to come > up with a list of requirements for the wgo platform (CMS). Help him with > the requirements if you want to help selecting the most appropriate > tool(s). > > If you can't stop discussing the CMS to be chosen anyways, don't forget > that after long debates Drupal is still the fittest candidate. If you > think Tool X is better please explain why, the more detailed your > comments are the most useful they will be. > > About i18n, there was a long discussion in gnome-web-list that got into > quite detailed aspects back in December05-February06 (i.e. > http://mail.gnome.org/archives/gnome-web-list/2006-January/msg00030.html ). John Hwang (aka tavon) is in charge of pushing the i18n policies draft by August 9th. If you want to get i18n right in wgo please help him summarizing what has been discussed and getting a good list of requirements. > > We don't have much time to discuss. If you want to help effectively it > is recommended to a) concentrate your contributions in one topic until > it is solved and b) try not to repeat discussions already held in the > past if you don't bring new ingredients. >
Attachment:
signature.asc
Description: This is a digitally signed message part