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/p
roject/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...
|
dwwright.n