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_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. -- 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_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.
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.oreillynet.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)" <frando@xcite-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/toshiba PlayStation 3 Auctions http://give-me-an-offer.com/offers/auctions/au1 Samsung HP-S4253 42" High Definition Plasma TV http://give-me-an-offer.com/offers/tv/plasma
On 12/16/06, Earnie Boyd <mylists@progw.org> wrote:
Quoting "Frando (Franz Heinzmann)" <frando@xcite-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.
I think one of the great things that Drupal has done is raised the bar for the use of version control by PHP developers. It's one of the things that has set us a bit apart. CVS branches are another level of complexity...something we need to spread even more to improve the quality of our code and ingrain best practices. HOWEVER....think of sandboxes as a "safe" place where you can experiment? Probably not something we can do indefinitely.... Maybe, either through the Drupal Association or through a friendly neighbourhood Drupal company, we can offer a CVS space for anyone... There are some existing free CVS spaces, too -- here's one that I found: https://freepository.com/services.html Maybe part of the handbook write up on sandbox (anyone have a link? ideally it should mirror in part what contributions/README.txt says) can gather some of these free resources. I opened a documentation issue for this: http://drupal.org/node/103700 -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
HOWEVER....think of sandboxes as a "safe" place where you can experiment? Probably not something we can do indefinitely....
Boris I see it more as a centralized way of sharing and collaborating code informally. Many times, I've heard people saying "get it from my sandbox". Or I go trolling through sandboxes to see how a certain hook is used or whatever. I have both SVN and CVS on my development server, but it is only for me and Wafaa. It is not centralized, and it is not a good sharing tool. One pillar of the success of Drupal is that there is a central repository for modules, rather than having things all over the place where they are hard to find. Sandboxes are somewhat similar to that, but developer to developer, off line, and informal. If the sandboxes are misused in anyway, then we tell those misusing them not to do so, but blanket bans of non-core code is a bit too far.
On 12/16/06, Khalid B <kb@2bits.com> wrote:
HOWEVER....think of sandboxes as a "safe" place where you can experiment?
Probably not something we can do indefinitely....
One pillar of the success of Drupal is that there is a central repository for modules, rather than having things all over the place where they are hard to find. Sandboxes are somewhat similar to that, but developer to developer, off line, and informal.
Yes, +1 -- see my later response after I actually caught up on all the threads :P -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
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
On 17 Dec 2006, at 5:57 AM, Steven Wittens wrote:
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.
you need a project before you can create directories in the normal cvs. and most of the things in sandboxes will never have projects created for them. and there's a lot of useful stuff in sandboxes, for the right people. Sandboxes are a way for developers to share code, and not meant for end users. Additionally, working on large core patches in sandboxes are not really ideal either. I've found it best to have an actual complete drupal core checked into a revisioning system, with multiple people having write access to it, to work on big core patches. Something which the sandboxes are not well suited to, and separate repositories are better for.
you need a project before you can create directories in the normal cvs.
I think I should go start the "sandbox module" (wink, wink) project. Anyone who wants access to commit changes to the (wink, wink) sandbox module can have it. -Mark (Don't email me about the sandbox project. I'm not starting one. This is a joke. End disclaimer.)
Mark Fredrickson wrote:
you need a project before you can create directories in the normal cvs.
I think I should go start the "sandbox module" (wink, wink) project. Anyone who wants access to commit changes to the (wink, wink) sandbox module can have it.
-Mark
(Don't email me about the sandbox project. I'm not starting one. This is a joke. End disclaimer.)
This is not a joke, the sandbox project exists: http://drupal.org/project/sandbox In order to get write access to /sandbox you need write access to that project. Cheers, Gerhard
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.
participants (12)
-
adrian rossouw -
Boris Mann -
Earnie Boyd -
Frando (Franz Heinzmann) -
Gerhard Killesreiter -
Gordon Heydon -
Karoly Negyesi -
Khalid B -
Kjartan Mannes -
Mark Fredrickson -
Morbus Iff -
Steven Wittens