[development] FAQ: Why is Drupal still using CVS when X is a much better choice?

[Ivan Sergio Borgonovo]

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
> needs.

> 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
drupal site.

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
http://www.webthatworks.it