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