CVS contribtions/sandbox changes

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

-- 
Kjartan

Hmm,
it is still not clear to me why you would 'close' the
sandbox.

Is it the 31 MB disk space that the sandbox needs?
Is it the fear of people storing copyrighted material there?
Or the fear of people being to lazy to actually release
their code as a 
module or theme and instead leaving it in a sandbox?

I think the drupal sandbox is a great feature for the
community that 
should be kept as it was. A place to play with drupal core
and to share 
pre-alpha / experimental code, no matter wether it's core or
contrib code.

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

Of course you should publish working code as a module or a
theme. But 
what about pre-alpha, not-yet-working code, experimental
stuff, mere 
ideas that you want to share? IMHO, this is what a sandbox
is for. To 
store code that is not yet ready for being published. As
soon as you 
open a project for it, people will expect that the code is
working or at 
least being worked on. That might not be true for some
pre-alpha or 
testing code, but this code can still be worthable enough
for some 
people, probably only developers, to be published somewhere.
And where 
to publish it if not in a sandbox?

So see this as a pledge of an very ordinary drupal community
member for 
the survival of the sandbox as it used to be ;)

Maybe just publish a policy that clearly states that a)
modules and 
themes should be published as modules and themes and not lie
in a 
sandbox and b) that only code closely related to drupal is
allowed to be 
stored in the sandbox.

regards,
frando

Kjartan Mannes schrieb:
> 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_o
rg_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.
> 

PS some quick stastics:
3204 files in total
2709 files with
^.*.(php|module|install|inc|mysql|sql|css|js|txt|po|pot|sql
|gif|png|jpg|pdf|swf|htm|html)$

    0 files with ^.*.(mp3|avi|mpeg|mpg|ogg)$

    3 files with size > 500 kbytes
   24 files with size > 100 kbyes
3099 files with size <  50 kbytes
2530 files with size <  10 kbytes

> Maybe just publish a policy that clearly states that a)
modules and 
> themes should be published as modules and themes and
not lie in a 
> sandbox and b) that only code closely related to drupal
is allowed

There already is one. Has been for years: see
contributions/README.txt.

-- 
Morbus Iff ( earth? shxt and scrambled eggs. earth? )
Technical: http://www.oreil
lynet.com/pub/au/779
Culture: http://www.disobey.com/
and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff /
jabber.org: morbus

Quoting "Frando (Franz Heinzmann)" <frandoxcite-online.de>:

>
> > 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.
>
> Of course you should publish working code as a module
or a theme. But 
> what about pre-alpha, not-yet-working code,
experimental stuff, mere 
> ideas that you want to share?

The use of CVS branches comes to mind.  A cvs branch is
created to 
place code for development of new features for already
released 
modules.  You then merge the HEAD and release changes using
cvs 
functionality to do so and then commit your changes as
appropriate and 
then clean up the branch.


Earnie
http://for-my-kids.com

--
--
************************************************************
******************
* The user of this server has agreed to allow the use of a
trailer in the    *
* mail that he sends for advertising purposes.  This
advertisment is added   *
* by the server and is not in the control of the user of our
services.       *
************************************************************
******************

Toshiba Satellite P105-S6114 Notebook
http://give-me-an-offer.com/offers/computers/laptop/t
oshiba

PlayStation 3 Auctions
http:
//give-me-an-offer.com/offers/auctions/au1

Samsung HP-S4253 42" High Definition Plasma TV
http://g
ive-me-an-offer.com/offers/tv/plasma

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

> HOWEVER....think of sandboxes as a "safe"
place where you can  
> experiment? Probably not something we can do
indefinitely....
>


I agree with Kjartan... sandboxes served a purpose, but
Drupal  
development has grown and is more formalized now.

If you used the sandbox before simply as a means of revision
control,  
there are better solutions now. Many developers now have
personal  
revision control systems, either hosted or distributed, for
their own  
coding. With services like Google Code, it is easy to
publish and  
maintain code online.

As far development of modules that is still in progress, IMO
the  
recent contrib branching improvements solve a lot of that.
You can  
now work on alpha-features while maintaining a stable
working version.

The sandbox as it is now is one big pile of code... mostly
crap, with  
some active pieces buried in it. Let's clean it up.

Steven Wittens

> I agree with Kjartan... sandboxes served a purpose, but
Drupal  
> development has grown and is more formalized now.

I just found a metaphor. Compare BarCamp with a formalized
conference.