[development] FAQ: Why is Drupal still using CVS when X is a much better choice?
Ivan Sergio Borgonovo
mail at webthatworks.it
Thu Aug 7 14:26:43 UTC 2008
On Thu, 7 Aug 2008 07:40:59 -0500
"Adam Light" <aclight at gmail.com> wrote:
> On Thu, Aug 7, 2008 at 4:45 AM, Ivan Sergio Borgonovo
> <mail at webthatworks.it> wrote:
> > From _my_ point of view as a user and as a contrib I'd feel happy
> > with Joomla approach as well.
> > I don't see any reason to ask for a cvs account on drupal to
> > develop my modules. I have my project infrastructure and if I
> > hadn't one I could pick up one from the many offered, building
> > up my preferred mix of bug tracking system, rcs, documentation
> > system, ... I may be missing something... if so please tell me
> > what could be the advantage for contrib and users to use drupal
> > infrastructure for project management I don't get. Other than
> > publicity what do I get from drupal infrastructure?
> > Making it clear (to me and to everyone else) what are the
> > advantages of using drupal infrastructure for project management
> > would surely help.
> Feel free to contribute in whatever way you feel best serves your
> Using the d.o infrastructure for project management does provide
> some real benefits to the user community as a whole and to
> individual projects. First of all, nobody has to worry about
> finding a service to use, or building their own. There are no RCS
> servers to maintain. Plus, there is a consistent interface to all
> of these tools across projects.
Drupal could still offer cvs (svn) etc... avoiding the need to look
around without forcing contrib to stick with "drupal way".
I really don't find these advantages worth the effort and pain of
the people maintaining project*. That's just me.
Furthermore the only consistent interface I see is cvs.
If you mean: information for users... the single project pages...
that's what other projects like Joomla or plone are offering without
the need of such a tight coupling with the rcs.
> In addition, the update_status module gets its information from
> drupal.org. If your module isn't hosted on d.o, then users of your
> module will not be informed of updates, whether these updates
> include security fixes, new features, bug fixes, etc. In
> addition, third party sites like drupalmodules that scrape
> drupal.org will also probably not know about your module. Less
> visibility often means less contributions from other developers.
It doesn't mean it could be achieved with other means that will put
a bit more work on contrib devs at the advantage of much less work
on drupal infrastructure and much more freedom for contrib.
We've rss, aggregators... and I think most drupal contrib have a
It doesn't seem that less coupling between the "community plumbing"
aspect and the project management infrastructure is having an
appreciable effect on other project flourishing of extensions.
Furthermore I think that project management needs for core are quite
different to the one of contrib.
In this situation the "status quo" looks better than investing more
resources into project* to support a different rcs.
I still don't feel like an exception seeing more ties than
opportunities in an even more structured project*. Am I?
> Plus, as you mentioned, the d.o security team only monitors
> projects hosted on the d.o infrastructure.
As said... I think the "patronage" of sec team is the most valuable
thing. I wonder if sec team actively scrutinise contrib modules or
just coordinate fix in core and sec announcement for contrib.
Ivan Sergio Borgonovo
More information about the development