Jump to:

Problem/Motivation

Currently, drupal.org users are allowed to create an unlimited number of "sandbox" repositories to hold experimental modules, code forks, and not-yet-published modules waiting for approval.

Once created, a sandbox project cannot be deleted. This pollutes the project namespace, as it is not possible to register a project whose name conflicts with a sandbox.

In fact, the only practical difference between sandbox projects and full projects is that the latter are allowed to have release nodes, and appear in the main project issue drop-down. See Sandbox (experimental) projects.

For this reason, many developers have resorted to using (e.g.) github for initial or experimental code development. @todo: explain why this is bad.

Many users have requested the ability to delete drupal.org sandboxes that are no longer relevant or which were never intended to be promoted to full projects.

Proposed resolution

Users should be able to delete their own sandbox projects, which would also delete any associated issues, comments, git repos, etc.

A warning should be added to sandbox pages stating that any content posted there may be lost if the sandbox is deleted.

Sandbox names should not conflict with full project names.

dww expressed some concerns in #29, but after discussion, agreed in #46 to move forward with this proposal, and even rolled an initial (untested) patch toward this end.

Josh The GeekCreditAttribution: Josh The Geek commented April 2, 2011 at 8:26pm

-1
I think that you shouldn't be able to delete sandboxes. If one contains a module that many people use, those people would be abandoned. If you really NEED to delete a sandbox, you should try in the infra queue.

Josh The Geek, I'd argue that people shouldn't be using a sandbox module without discussing it with the author. My understanding of the point of the sandbox was that it provides a means of working on, and potentially collaborating on, a project that is not ready (and may never be ready) to become a publicly available module.

Josh The GeekCreditAttribution: Josh The Geek commented April 2, 2011 at 11:38pm

Hey, no one says you have to maintain a sandbox. One part of sandboxes is that you don't have to maintain them. If someone else comes along and wants to take over a project for you, you grant them maintainer, and you don't have to ever look at the project page again. So, instead of deleting your sandbox, or even deleting your code, I think that you should just leave the project with a note that says the project is unmaintained and if you want to become the maintainer, you can, and also mark as abandoned/obsolete.

Josh The Geek, the counter argument to a sandbox project getting marked as abandoned instead of deleted is that they are by design free flowing projects that, if someone was really passionate about and wanted to keep going, they could start their own sandbox project for and keep alive instead of working off of a test page that the original committer doesn't want to deal with anymore. If we're going to get silly about these sorts of arguments, my freedom to clean out and remove my unwanted sandbox projects should not be trumped by someone else's want to use the experimental code I've posted there, especially when they have a perfectly good forum to keep it going if they still find it useful, their own sandbox project!

I want to delete one of my sandbox projects, and then add it back again, because I didn't do it properly the first time. I used to maintain the project somewhere else using svn and when I put it in drupal.org I did not migrate the svn history. Now that I know how to use git svn I would like to do it again properly, maintaining the previous history. Is there a way to put the old revisions back in without deleting the project?

+1 For sandbox deletion. If someone is going to use code from a sandbox project, it already comes with a fairly strong Caveat Emptor. Also, if a user has been using code from a sandbox project and that sandbox gets deleted, there's really nothing to stop them from posting it into their own sandbox, right?

Sandbox projects are by definition experimental so someone should not rely on them anyway. I recently created a sandbox to port a module to D7. That code is now in the official project so the sandbox is no longer needed and someone else would be worse off if they used it instead of the official project. Not being able to delete sandboxes would make me just want to use github for "experimental" code.

No, we've been over this, and we really don't want drupal.org nodes and git repos to be out of sync. That said, I'd love to see this as well. I'll have to look and see where we're blocking the deletion of projects. We may have to work with that code in drupalorg if that's where it lives.

I have an internal server error on my test sandbox and I'd like to simply delete my sandbox and start over, using the same vital statistics as when I started, but I can't figure out how to do this. Is there a way to delete a sandbox and just start over?

Even when per-issue repos are created, it would still be nice to delete sandboxes. A working example is the Search API Facet API Integration sandbox. The integration is complex, so it helps to give multiple maintainers access to commit as well as maintain a separate issue queue for tracking issues that pertain only to the integration. If you look at the #1182614: Integrate with Facet API issue, it was really hard to track everything in one thread. Once the code is merged into Search API, the sandbox will be useless and I will want to remove it.

Huge +1 for being able to delete sandboxes, because I see myself using this workflow more an more.

A) We normally never delete nodes on drupal.org unless they're spam. Losing history is potentially bad.

B) What happens to all the issues attached to a sandbox project that's being deleted? Do those just become orphaned issues? Do we delete those, too? Now you're really getting into dangerous territory. What if you forked core into a sandbox to work on some tricky problem. I came along and posted a really thorough comment explaining some important aspect of core. Took me hours to research and compose. Then the sandbox author decides they're tired of working on this project and deletes their fork. And now my comment is gone. That sucks. Sandboxes are collaboration tools, and it's not just up to the sandbox owner to decide to destroy other people's work.

C) You can already mark projects as "Abandoned". What's wrong with just doing that when you're tired of a sandbox? The only counter-argument I've heard is that people want to clear stuff out of http://drupal.org/project/user and the listing of their projects on their profile page (e.g. http://drupal.org/user/46549). Could we just solve this by saying that projects marked with the "Abandoned" term should be excluded from those listings?

So, I'm not going to "won't fix", since clearly there's a lot of support for this. But, I'd like to hear people address my concerns before we plow forward with this.

John PitcairnCreditAttribution: John Pitcairn commented August 10, 2011 at 10:44pm

Maybe the issue is terminology then. Maybe these shouldn't be called "sandbox" projects. If other users can comment, open issues against the project, make use of the project in live sites (fools!), clone the repository, fork it, etc, and the project owner cannot prevent that or remove any of it, then I really don't see there's all that much of a distinction between a sandbox and a "real" contrib project?

@dww while I still think that having disposable repositories in drupal would be a Good Thing, I can understand you point.
I would propose the following: if a user abandon a sandboxed project, the project will not be reported among the user projects in user profile contribution will move from "project the user currently mantains" to "contribution to project not mantained by %user" (see #1246598: Split "My Projects" into two lists: "Projects Maintainer of" and "Projects Contributed to"), and the user will be removed as mantainer from the project page.
And a BIG message on top of the project page like "don't use unless you know what you are doing, very bad things will happen" :)

Regarding #29B - How about allowing deletion of sandbox projects where there are no issues associated with it (or no comments from anyone other than the sandbox owner)? That the sandbox owner could clean up false starts, mis-named projects, or training projects that will not be of use to the Drupal community. Those type of nodes are much like spam, no?

A) Cleaning history should be done more often. All too often, when searching the internet, or just this site, the results are utterly polluted by outdated knowledge/insights/procedures/etc. In general, I also think that people should have the right to unpublish things and that this right should prevail the interest of history keeping.
B) Deleting a project should (at first sight) indeed be a cascading delete, thus including issues, repo's, tarballs, whatever. If there are issue(-comment)s that are worth saving, they can probably be linked to another, still existing, project that apparently profited from the work done in the sandbox project.
C) Pollution of search results won't be prevented by marking things as abandoned.

Concluding: IMO concern B is valid. A possible solution to this concern of dww could be to not give sandbox owners the delete project permission but instead have them post an issue to the same queue as where they apply for full project access, so that other people can have a quick review of what would get lost. Such issues should be well documented (as applications for full project access):
- reason: e.g. 'code integrated into other project' or 'it appears that other projects exists that do the same (and more)'.
- non-severance of loss of history: '(interesting) issues are moved to the same queue as where the code moved' or 'there were no issues' or 'there were only simple bug reports'.

I know this queue has a backlog, but that should not withhold us from doing the right thing here.

Sandbox projects titles namespace pollute the allowable project titles because of the autocompletion features in issue reassignment i suppose. You cant name a project something if a sandbox already uses the title.

I probably wouldnt create sandboxes if i knew i couldnt delete them. They are by their nature experimental and disposable and in being so are somewhat unique on d.o. Its no skin off my back either way going forward i just probably wont use them and will use github instead for sandboxing which id rather not do.

We normally never delete nodes on drupal.org unless they're spam. Losing history is potentially bad.

Sure; nodes are set in stone. But would it be so bad if sandboxes were set in ... sand? If sandboxes are forever, they should be renamed diamondboxes to reflect that mindset.

What happens to all the issues attached to a sandbox project that's being deleted? ... it's not just up to the sandbox owner to decide to destroy other people's work.

If a sandbox is forked from core or any other project, typically there will be a related issue attached to the parent project. That's where discussion of the tricky problem happens, not in a sandbox issue queue.

If a sandbox is intended for later promoted to a full project, typically there will be a related project application node where such discussion happens.

For the remaining (possibly hypothetical) cases, I think the solution would be to show a disclaimer on sandbox issue pages warning that content posted there is temporary and may be deleted at the whim of the sandbox owner. If you don't like those rules, go play in your own sandbox.

You can already mark projects as "Abandoned". What's wrong with just doing that when you're tired of a sandbox? ...

Nobody is suggesting that we eliminate the "abandoned" approach in favor of deletion. If I wrote some code that I'm tired of maintaining but which may be of use to someone else, I'd still take the "abandoned" approach. But if I wrote some code which is clearly and fundamentally flawed, or which has been merged into or obsoleted by another project, or whose name should be returned to the general pool for re-use, I'd welcome the opportunity to clean up the clutter.

I have exactly one sandbox project at the moment. It has no code, no issues, no users, no maintainers, and no purpose other than as a placeholder for a name that I may never use. I was thoroughly dismayed to discover that I cannot delete it, and so long as that remains true, I will never create another.

Updated the issue summary. Also, I have an idea for compromise/resolution:

Rather than a "Delete" button, sandbox (and project) owners should have an "Abandon" button.

Clicking on the "Abandon" button should, after a warning, remove the user from the Maintainers list for that project/sandbox.

Ownership would automatically be granted to the most senior maintainer, if any.

Sandboxes or projects with zero maintainers should be marked "Abandoned/obsolete" and assigned to the "Abandoned projects" user.

All abandoned projects should be added to a special "Abandoned projects" page.

Any user who already has the "Create project" privilege should be able to claim an abandoned project, thus becoming its new owner.

Full projects in the "Abandoned projects" list should be automatically deleted when their latest release is no longer supported. Currently, that means if the latest core version supported by an Abandoned project is 5.x, then it should be deleted. There's no sense in carrying cruft around forever.

Sandbox projects in the "Abandoned projects" list should be automatically deleted after a grace period of (e.g.) six months. That gives everyone who cares a reasonable chance to rescue their pet fork/branch/feature, while allowing truly unwanted stuff to eventually disappear.

Just came across this thread when trying to do this. I'm still for the ability to delete sandboxes. I understand and appreciate the points in #29, but in general I agree with the counterpoints in #35 and think that they outweigh the concerns.

Specifically in regard to point B, about sandboxes used as collaboration tools: I'm wondering, firstly, how much of an edge case this is, and second, whether it could be solved at the personal level by the author simply not deleting those projects, at least not until the other collaborators have been consulted. This seems to me like an area where courtesy should be the determining principle instead of UX.

Also, is it possible on d.o to just unpublish the nodes? Then those comments could be retrieved if they were ever needed.

I favor sandbox deletion, strongly. It is a much saner workflow - we should have disposable repos on d.o, and sandboxes were always originally intended to be that. And the deletion should be cascading to all issues. The issue raised by dww about losing a valuable comment/issue is an edge case. I'd like to think that anyone who creates a sandbox with enough interest will take the care to reassign any valuable issues before closing the sandbox. Failure to do so would generate a nontrivial social backlash, and that's really the best deterrent.

I also think that there should be *no* namespace collision issues between sandboxes and projects. This applies to my pre-migration desire that sandboxes have real shortnames, as well.

I favor sandbox deletion, strongly. It is a much saner workflow - we should have disposable repos on d.o, and sandboxes were always originally intended to be that. And the deletion should be cascading to all issues. The issue raised by dww about losing a valuable comment/issue is an edge case. I'd like to think that anyone who creates a sandbox with enough interest will take the care to reassign any valuable issues before closing the sandbox. Failure to do so would generate a nontrivial social backlash, and that's really the best deterrent.

I would definitely like ++ that. I'm a perfect example - have 2 projects right now one of which i had to dump, and I can't delete it. Also, it's very helpful if you mess up with git and don't know how to fix it

Committed, pushed, and deployed live. The "git user" role now has the "delete own sandbox projects" permission.

Sorry for the delays here. I had actually committed this a while ago but hadn't had a chance to deploy and reconfigure permissions. Since the code just went live with another deployment I had to do, I saw this in the diff and remembered I needed to configure this.