[development] sandbox, project nodes, release nodes, and drupal.org's contrib CVS repo

[Derek Wright]

wow, go offline for a few days and behold the mayhem that can break  
out on this list. ;)

personally, i wasn't in favor of disabling the sandbox in the first  
place, and am happy to see the change reverted.

that said, after reading all the related threads, i've noticed a few  
important misconceptions about how project nodes, release nodes, and  
our CVS repository interact with each other.  i'll grant that all of  
this has been in flux (hopefully for the better) for the last year,  
but i think it's essential to clear these up as this discussion of  
the sandboxes evolves:

- you do *not* need a project node before you can add a directory to  
the contributions/modules or themes directories.  in fact, it's the  
other way around... the directory must exist in CVS before you can  
add the project node that points to it.

- you *must* have a valid CVS account before you can add a project node.

- before, project nodes were unpublished until there was a tarball  
generated for that project.  this was (IMHO) a hack to get around the  
problem that we didn't want to maintain both a list of users with CVS  
accounts and a corresponding drupal role.  so, anyone with an account  
on d.o used to be able to create a project node for something, but  
only once their CVS account was approved, and they committed code,  
and the packaging script ran, was a tarball generated and their  
project node published.  now, only people w/ CVS accounts can make  
the project nodes, so they get published right away, and the  
existence or not of a release associated with the project has no  
bearing on if the project node is published, (and therefore, if the  
issue queue works, etc).

- you *need* to have a valid *release* node for a project for it to  
appear in the project browsing pages (the "Downloads" tab on d.o,  
a.k.a http://drupal.org/project/Modules etc).  those pages basically  
say "show me all the projects that have a release that matches the  
version i'm looking for".  no release means you don't show up there.

- our CVS access control (the "CVS access" tab on projects) only  
kicks in once there's an actual project node for a given directory in  
the repository.

- creating a DRUPAL-4-7 branch for your project no longer  
automatically creates releases for it.  so, you can even branch/merge  
your code before it's ever got releases (and therefore, visibility in  
the project browsing pages).

here's an imaginary story for how all of this works together to give  
us some better alternatives than the sandbox for code in various  
states of not-yet-ready-for-end-users:

a few folks want to collaborate on a new contrib module.  no one is  
sure if it'll work, or who's going to maintain it, but they want to  
start hacking now.  they add it as a new directory in contributions/ 
modules but DO NOT create a project node yet.  anyone w/ a CVS  
account can collaborate in there, but it's basically invisible to end  
users[1].  later, they decide they want to start using an issue queue  
to coordinate bug fixes/features/tasks, so they create the project  
node and enable the issue tracker, but they still don't make any  
release nodes.  the project is still basically invisible to end users  
on d.o since it's not in the usual project browsing pages.  end users  
would only find it if they happened to search for the right term, or  
stumbled upon the project by noticing it in the enormous dropdown box  
when selecting a project when adding another issue or something.   
and, assuming our imaginary team of drupal ninjas were being  
responsible, the description on the project node (and the README.txt  
in CVS) would be full of bold, flashing warnings that "THIS CODE IS  
ALPHA -- BEWARE".  but, people-in-the-know would now have a) an issue  
tracker, b) CVS access tab, c) all the cool CVS integration project +  
cvs.module provide (the "Developers" page, commit messages, etc).

perhaps the story ends there, they give up, move on/abandon the  
project, whatever.  maybe someone else comes along 9 months later and  
wants to pick up the torch again (and the infra team just hands over  
ownership of the project node to the new victim).

instead, maybe their experiment works and they want to release their  
code.  they just have to start adding tags and release nodes and  
poof, the project now shows up on the end-user-visible project  
browsing pages.


so, while i'm happy to see the sandbox remain for cases where that's  
useful, i'd like to offer the above scenario as a good alternative  
for "pre-alpha" modules or themes.  i think it's better because:

a) it's more structured
b) you can use an issue queue
c) if it ever goes "live", early development issues are still there  
for reference, CVS commit messages (and therefore "cvs blame") can  
point to issue nids, etc.
d) you can use the CVS access tab to ensure only the people you mean  
to be are hacking on your code
e) you get a project node to use for description, news, etc.
f) you can classify the module as appropriate so people looking at  
the project node don't just know it's a module, but what kind of  
module it is
g) it forces you to pick a name for your thing, which will help  
prevent you from *exact* duplication of another existing project with  
the same name
...

cheers,
-derek (dww)

[1] people who just do "cvs checkout contributions/modules" and then  
complain about how much crap is in there don't count in my book. ;)   
if you're getting drupal source directly via CVS you're already over  
a fairly high bar and i don't consider you the target audience we  
need to protect from yourselves.  it's clear that we already have no  
guarantee of quality for what's in there now (even projects with  
releases), so the idea that "it's in contributions/modules, it must  
*sort* of work" is inherently flawed.  if there are official releases  
(not dev snapshots) with clear, useful release notes, you can  
probably assume it works (even then, review it yourself or pay  
someone on the security team to audit it for you before you really  
trust it).  if not, you're on your own...