[development] CVS contribtions/sandbox changes
Gordon Heydon
gordon at heydon.com.au
Sat Dec 16 23:31:34 UTC 2006
Hi,
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
that.
Please don't remove the sandboxes as I find them an valuable resource in
developing new code for Drupal.
Gordon.
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