[development] CVS contribtions/sandbox changes

Gordon Heydon gordon at heydon.com.au
Sat Dec 16 23:31:34 UTC 2006


I disagree with the removal of the sandbox. I use this a lot for 
pre-alpha code. and also to share custom modules that I know other 
people are wanting to get and use, but I am not willing to create a new 
project to yet. Generally this is because there is too much site 
specific client stuff that I need to remove.

In the past I have also commit other modules like the image module where 
I have made a lot of changes and these were then taken later by other 
people and incorporated back into the main module.

Laterly I have been using my sandbox as a place to share the new invoice 
module for E-Commerce. I have been able to run this module in a lot of 
different places, and not have to fully support it. It is not in the 
HEAD of ecommerce and I was able to shake out a lot of the bugs because 
of the sandbox.

Other uses that I and other people s to share modules that I have 
written. But as yet, I do not want to do a full release.

I agree that the sandbox needs to only contain Drupal related content, 
but I do feel that it is a great place to share very early code which is 
not ready to become a full project with all the other stuff that follows 

Please don't remove the sandboxes as I find them an valuable resource in 
developing new code for Drupal.


Kjartan Mannes wrote:
> Greetings,
> Originally the Sandbox was created as a place to put core patches that 
> were pending review, as we did not have any issue tracker back then. 
> Since then the project module has grown and can now cover most of the 
> original purpose of the sandboxes. Since then sandboxes have been used 
> for many original uses, some that are good and some that aren't so good. 
> The good stuff are what the sandboxes were originally intended for, 
> large or very experimental Core changes that weren't ready for a proper 
> issue. The bad stuff is people using it as a place to store modules and 
> themes, this has always been a bad idea as you loose out the option of 
> using issues tracker, versions, and they are rarely included in searches 
> for any new wide spread security vulnerabilities.
> Since sandboxes still have some limited use we aren't completely getting 
> rid of it, but it will be cleaned up. To make this happen we have made 
> the current sandbox directory read-only, and only approved people can 
> commit new files and changes. All the current data in the sandboxes will 
> remain there until January 15, 2007. Sandboxes who have had people 
> request write access, and had this granted will remain and all the rest 
> will be archived and moved out of the repository. To request access file 
> an issue against the infrastructure tracker 
> (http://drupal.org/node/add/project_issue/drupal_org_maintenance) it 
> will then be handled. I'm pretty sure the CVS administrators will be 
> lenient with regards to what is considered core patches and experimental 
> stuff, but I doubt we will approve people using the sandboxes as a place 
> to host mp3 collections, non-Drupal projects or even whole websites.
> Modules and themes that are in active use and/or development will be 
> moved to the proper location upon request, this will preserve the CVS 
> history whereas re-committing them to the right place will loose the 
> history. Please file an issue on the infrastructure tracker for this: 
> http://drupal.org/node/add/project_issue/drupal_org_maintenance.
> I know some people will be unhappy with these changes, but having 
> thousands of files randomly stored in the CVS repos doesn't add value 
> most of the time. We definitely want to help provide the tools for cool 
> Drupal developments, but it will happen under slightly more orderly 
> rules than the current wild mess.

More information about the development mailing list