docsWiki

[David Bovill]

On 26 Oct 2005, at 21:36, Marielle Lange wrote:

> Drupal is  cleanly designed with extensibility in mind and more  
> flexible. Drupal provides a standard high-level API for developing  
> extensions and making it easier to extend Drupal in a standard way  
> with uniform look-and-feel. Drupal provides better support for  
> internationalization through i18n module. Drupal has better support  
> of Search-Engine-Friendly URLs in core and through modules. Drupal  
> supports multiple sites with a single installation with fine- 
> grained access control and ability to selectively share  
> configuration settings and database tables. Drupal comes with  
> better templating system.

Sure Drupal is nice. There are a couple of projects I have been  
partially involved with that use Drupal - no real complaints.
> <http://www.flickr.com/photos/thox/24237747/>    ... Drupal XUL  
> with XMLRPC. Anticipating the future, xul compatibility is  
> something very good to have.

Yes - not exactly live yet :) Also Drupal XMLRPC is a php file! -  
drupal is written in python by the way. This is quite telling:

     - http://trac.civicspacelabs.com/cgi-bin/trac.cgi/file/trunk/ 
modules/drupal.module

  The XMLRPC library and Drupal being documented and maintained using  
Trac! Basically Drupal is great for a kitchen sink community site,  
but it is not a dedicated developer resource tool. We don't need all  
the Drupal stuff - we need effective collaborative software  
development tools integrated into Rev.

>>     3) Code and binary stack versioning linked to wiki documentation
>
> Drupal features content versioning. It also supports taxonomy  
> support  (we will need this too, this will become more and more  
> important over the next 3 years).

Content versioning is not code versioning - most wiki's don't store  
the full history, can loose historical data, and do not support  
anything other than recent versions - no support for binary  
versioning (ie stacks) and no branching etc


>> Additionally I have requirements to add the following:
>>
>>     1) Issue tracking (tickets) and milestone support
>
> This means there is a main manager and a support service. Is this  
> realistic? If you propose support, you give users a reason to  
> expect it. Do we really want that (i.e., to end up doing  
> revolution's job)? Isn't open comments more appropriate?

No. Just an organised way for people to report problems and plan  
their sub-projects - milestones etc. i can see people using it to  
develop components they wish to release and possibly sell - a few  
people would use this if it helps them cooperate with other  
developers to achieve their goal - and is easier to use than setting  
up something themselves.

> Best is probably to install both and put them to the test for a  
> month and then check up what are their pros and cons (often you  
> discover annoyances only by experience).
>
> Shall we move this to a small group discussion? (somewhere on a  
> wiki, with occasional reports on this list)

I would say not until there are more than 2 and a half of us :) Also  
my guess is the discussion of wiki / web site integration with Rev is  
not entirely off interest to the list - even if they don't fancy  
actively supporting something that involves work yet :) Any request  
we move the discussion elsewhere?