Re: [development] Seems I need to take sandbox in my own hands
i'm just going to toss this out there as a general proposal: 1. move the sandbox completely out of the contrib repo, and make a new one -- this has the dual benefit of moving our 'messy' space away from our 'clean' space, and making the checkouts of the contrib repo faster/cleaner. you can then checkout the mess if you choose to. :) 2. in the new 'sandbox' repo, put a limit on how much each user can have in their active folder -- maybe 1 or 2 MB, which should be plenty for an experimental code home. i think this would be a pretty easy thing to implement. this would allay any bandwidth/space concerns about our chaotic space. i love the idea of having a more clear policy of what goes where, and setting up systems that encourage collaboration. i feel that a community place for chaos belongs in that map somewhere...
On 12/17/06, Chad Phillips -- Apartment Lines <chad@apartmentlines.com> wrote:
i'm just going to toss this out there as a general proposal:
1. move the sandbox completely out of the contrib repo, and make a new one -- this has the dual benefit of moving our 'messy' space away from our 'clean' space, and making the checkouts of the contrib repo faster/cleaner. you can then checkout the mess if you choose to. :)
2. in the new 'sandbox' repo, put a limit on how much each user can have in their active folder -- maybe 1 or 2 MB, which should be plenty for an experimental code home. i think this would be a pretty easy thing to implement. this would allay any bandwidth/space concerns about our chaotic space.
i love the idea of having a more clear policy of what goes where, and setting up systems that encourage collaboration. i feel that a community place for chaos belongs in that map somewhere...
Good points, however, I don't think bandwidth and space is the biggest concern atm, but a few megs is plenty of space to experiment with. Another option would be to have some sort of filter at drupal.org, e.g.; Show only modules which are... [X] Stable [X] Beta status [X] Actively maintained [_] Experimental (warning: this might be unstable) The same goes for themes, I have been thinking about maybe creating a few themes/modules and putting them at drupal.org but I do nit have the time to maintain them, so they would end up laying dead and screwing up users sites. -- // Johan Forngren /**************************************** Email: johan@forngren.com Site: http://johan.forngren.com/ Skype: forngren MSN: johan@forngren.com IRC: forngren @ freenode Jabber/GTalk: forngren@gmail.com ****************************************/
concern atm, but a few megs is plenty of space to experiment with. Another option would be to have some sort of filter at drupal.org, e.g.;
Show only modules which are... [X] Stable [X] Beta status [X] Actively maintained [_] Experimental (warning: this might be unstable)
I somewhat think you want to provide access to the sandboxes from http://drupal.org That's not something I would desire. We are talking of a space where developer-to-developer sharing happens. These not "might be" unstable but are almost guaranteed to be. They are very far from being ready for any form of end user consumption. Developers can use CVS (and ViewCVS in case of need) to get this code. End users should be barred from these.
As a mostly end user, I might like to know if someone was working on something or at least thinking about it, without being able to actually try it. This could probably be handled by a forum topic preannouncing things. There may be something like this already. An example might be trying to find out if anyone had thought about some new payment gateway and how serious they were. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Karoly Negyesi Sent: Sunday, December 17, 2006 6:33 PM To: development@drupal.org Subject: Re: [development] Seems I need to take sandbox in my own hands
concern atm, but a few megs is plenty of space to experiment with. Another option would be to have some sort of filter at drupal.org, e.g.;
Show only modules which are... [X] Stable [X] Beta status [X] Actively maintained [_] Experimental (warning: this might be unstable)
I somewhat think you want to provide access to the sandboxes from http://drupal.org That's not something I would desire. We are talking of a space where developer-to-developer sharing happens. These not "might be" unstable but are almost guaranteed to be. They are very far from being ready for any form of end user consumption. Developers can use CVS (and ViewCVS in case of need) to get this code. End users should be barred from these. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.22/590 - Release Date: 12/16/2006 5:39 PM
"Karoly Negyesi" wrote:
I somewhat think you want to provide access to the sandboxes from http://drupal.org
That's not something I would desire. We are talking of a space where developer-to-developer sharing happens.
I would challenge that premise (unless you are quoting some policy, of course). It is not true that the sandbox is useful for only "dev-to-dev" sharing. See below, regarding "barred from these".
These not "might be" unstable but are almost guaranteed to be. They are very far from being ready for any form of end user consumption. Developers can use CVS (and ViewCVS in case of need) to get this code. End users should be barred from these.
While I'm not entirely sure if you mean to equate "these" with "CVS and ViewCVS" only or if you mean end users should be barred from accessing the sandbox entirely, I think you must mean the latter. In that case, let me argue that end users can and do precisely benefit from being able to review the contents of the sandbox. Not only have I personally found modules, unsupported and in-progress, that worked just fine in my environment. Or, they were so close that only a minor change was needed. Furthermore, there have been occasions when the on-going work discoverable in the sandbox preventing me from setting off on a course which had already been traveled. One of _the_ hallmarks of Drupal, from an end-user perspective, is this kind of potential discovery and sharing. From whole "modules" ready-to-go down to small kernels of code (snippets, theme snippets, in-progress-dusty-grungy-sandbox-grit), Drupal is _open_ and _accessible_. Frankly, I would consider any kind of end-user "lock out" from the sandbox to be the first sign of a walled gate. I do understand all the arguments in the thread. Resources, policy, cleanliness, standards, logical organization, and so on all are very important. Discussions about the sandbox have been cogent and thoughtful, I thought. I only encourage that this same level of consideration be given to the decision to "bar" end users from downloading code, if that was Karoly's intent. (Note: Perhaps re-thiking the nature and purpose of, and therefore the on-server handling of, the sandbox space will also suggest some alternative end-user interface to the downloadable-accessible contents. If it does not make technical sense to provide end-user access through the current web interface, then perhaps some additional "public" flags could allow individual authors the choice to make certain content end-user accessible.) -- inkfree press
On 12/17/06, inkfree press <inkfree@gmail.com> wrote:
(Note: Perhaps re-thiking the nature and purpose of, and therefore the on-server handling of, the sandbox space will also suggest some alternative end-user interface to the downloadable-accessible contents. If it does not make technical sense to provide end-user access through the current web interface, then perhaps some additional "public" flags could allow individual authors the choice to make certain content end-user accessible.)
No. You're a "dev" if you can use CVS to access stuff. You're an "end user" if you click on links to download modules. The stuff there is "public" and anyone that knows CVS can go and go it Many threads, all veering off target. I think we've got consensus that: * sandboxes should stick around * we'd like to be flexible about what's in there for community sharing, but policy needs updating * maybe they should move to a separate repo -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
+1 Sorry, if i've joined the conversation a bit too late. On 12/17/06, Boris Mann <boris@bryght.com> wrote:
On 12/17/06, inkfree press <inkfree@gmail.com> wrote:
(Note: Perhaps re-thiking the nature and purpose of, and therefore the on-server handling of, the sandbox space will also suggest some alternative end-user interface to the downloadable-accessible contents. If it does not make technical sense to provide end-user access through the current web interface, then perhaps some additional "public" flags could allow individual authors the choice to make certain content end-user
accessible.)
No. You're a "dev" if you can use CVS to access stuff. You're an "end user" if you click on links to download modules. The stuff there is "public" and anyone that knows CVS can go and go it
Many threads, all veering off target. I think we've got consensus that: * sandboxes should stick around * we'd like to be flexible about what's in there for community sharing, but policy needs updating * maybe they should move to a separate repo
-- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
participants (7)
-
Ankur Rishi -
Boris Mann -
Chad Phillips -- Apartment Lines -
inkfree press -
Johan Forngren -
Karoly Negyesi -
Walt Daniels