Allow the deletion of sandbox projects

I second this. Since my sandbox projects aren't real projects I ought to be able to delete them when I feel like it. I've been looking for another issue about this but haven't found one.

+1

We should definitely be able to clean up our sandbox and purge unwanted projects.

+1 from me. I was just fooling with the sandbox capability for git-testing purposes, committed a custom module from among many I use, wasn't really intending it would get any attention, but it has.

I guess our only option at present is to delete all files, commit, and mark it obsolete/not maintained?

Since were all voting, +1 and subscribe.

It would be great that we can delete sandbox projects!

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

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.

+1

+1

alternatively..
add a system warning message, to the add project page, clearly stating that sandbox projects CANNOT be deleted once created ?

+1
I have a sandbox project, and merging a another Drupal project.
I would delete sandbox, but i don't. :(

+1 subscribe.

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?

Once per-issue repos exist, I will care much less about this, but since I've used sandboxes as a feature branch of a module I don't maintain, it'd be nice to delete it once the code is merged in.

+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?

This would involve also changes drupalorg modules to remove git repo from disk, but IMHO it's a good idea to let people remove un-used stuff(aka let people help use clean).

Moving to project, where project sandboxes feature lives to ask for maintainers opinion on this.

+1 You should be able to delete them. They are supposed to be for testing purposes of many kinds.

Hope you can change it.

+1, if you depend on a sandbox and it is removed, create your own sandbox

+ 1

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.

What about deleting but keeping the repo? The user could add something like a special text file to notice that the repo isn't active anymore and you should use remote FOO

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?

+1

Some of us have created sandbox projects just to get a handle on the environment, but the code is not generally useful. We should be able to delete such scrap projects.

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.

+1
We should be able to clean up our sandbox.

+1

I'm generally -1 to this for the following reasons:

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.

Thanks,
-Derek

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?

See http://drupal.org/node/1011196 for documentation on the differences between full projects and sandbox projects.

@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" :)

EDIT: proposal amended, changes emphasized

My support of the idea of removing sandboxes hadn't taken into account the related aspects dww raised. Taking those into account, just nuking them is a bad idea.

I think, though, that xlyz's suggestion would satisfy my need.

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?

I'm a +1:

Regarding the concerns of dww (#29) my opinions are:

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.

+1

Subscribe.

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.

Subscribe

I probably wouldnt create sandboxes if i knew i couldnt delete them.

Same here. I'd probably have used more than the one I did create.

Add "garbage collection" proposal.

added "project namespace" to the pollution issue.

Issue summary updated.

I am going to attempt to address the concerns raised by dww:

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

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

3. • 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 from issue summary template.

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.

Updated summary with possible resolutions/answers gleaned from the discussion.

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.

Trivial typo correction.

Updated with input from dnotes.

Added MasterChief to the "should be able to delete" list. Not that voting matters...

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.

added nevergone, Webappz and jim0203 to the "+1" list.

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.

Yep. Agreed with all of that.

Yeah, I'm glad I raised my concerns, but they seem to have been pretty well addressed.

This patch is sort of a hack, but it probably works. I haven't yet tested at all (beyond php -l). Would be nice to add simpletests for this, too.

Added sdboyer's input.

I've deployed this to http://webchick-drupal.redesign.devdrupal.org/ (user/pass: drupal/drupal, then log into Drupal with bananas/bananas to test)

I gave both "Git user" and "Git vetted user" roles the permission to "delete own sandbox projects".

@webchick i tested creating and deleting a sandbox on your test site. not sure if that is what you wanted ;)

The sandbox along with issues to that sandbox are deleted.

One issue is after visiting a removed issue node you are directed to '/node/add/project-issue' with a message "Invalid project selected."

Should that redirect to a default "this issue has been removed" node?

Tested #47 webchick's website. I created and deleted a project.
I did not test git on that project

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

@webchick performing the steps necessary to fix this ;)

+++ b/project.moduleundefined
@@ -826,7 +828,21 @@ function project_project_access($op, $node, $account) {
+      if (user_access($any_perm, $account) || (user_access($own_perm, $account) && ($account->uid == $node->uid))) {

Whenever I see mixes of || and && in a conditional, I do a doubletake. Can we get some extra parentheses around this to clarify the order of operations?

Otherwise, this looks great.

@tim.plunkett the parenthesis are already double-taking

@tim.plunkett the parenthesis are already double-taking

What? I think we've a translation issue here. However, #53 is correct in saying (I think) that the && condition is already properly wrapped in parens.

Whew, my eyes must have been crossed, it was after midnight for me. RTBC from me as well!

No problem. It was almost 4am here! =D

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.

I verified it worked....thank you!!!

It worked for me too. Thank you