Robert Douglass wrote:
Gerhard Killesreiter wrote:
The actual proposal was actually brought up by somebody else and was to completely remove the sandboxes. I opposed this and hence see it as a bit ironic that you mention me first...
Let me be the first to thank you.
:)
Usually in a case like this, one side of the story isn't fully understood. I have to admit that I still don't understand what is so bad about the sandboxes that makes the people involved with infrastructure hate them. I use my sandbox only infrequently but am very glad it is there.
Why? A recent commti you did was your memcached code. Does this need to be in a sandbox? Shouldn't this rather be an attachment to an issue or even a project?
Possibly. But if I create a project called "memcache", check in my alpha code, and then don't touch it again for the rest of my life, that will be a real hassle for someone who wants to write a better memcache module in the future.
Sorry, but that's nonsense. If somebody wants to take over this project, we'd give him write access.
By putting it in my sandbox I am deliberately saying "Beware! The odds of this code being crap are 98/100"
If it is that bad, you shouldn't even put it there.
Of these only the last one needs (IMO) revision control and we could amend the rules to allow for this. For the first use cases a file upload to an issue or the snippet repository in the handbook should be fine. It is actually better there because it can be more easily found.
Yes I agree with your points. There are cases where uploaded code snippets are more useful than code snippets in a sandbox.
Glad we agree on this.
The work that goes into Drupal.org infrastructure is chronically under-appreciated, and if the sandboxes are a special burden that I (we) haven't recognized, it would help the conversation to find that out.
They are simply uncontrollable, nobody is really accountable for the stuff in there etc. If this is a problem I don't see that moving the code to any other location will fix it.
It will fix it for modules with project nodes since these are protected.
A code snippet uploaded to an issue is just as much a danger as that in a sandbox, with the exception that more people (who don't have CVS skills) will see it, download it, try it and break things with it. In a way the sandbox is nicely insulated from the normal Joe user who is feeling daring and wants to become a support case today - "help, I broke my site! what do I do now?"
Just attach a warning message and we can happily ignore the ignorant user.
And most of the stuff is crap that nobody will understand, ie is completely undocumented and thus unusable by anybody but the author.
Again, the proposed fix does nothing to solve this problem, in my opinion.
Not directly, but if people have to create a project node (in order to protect their stuff from being modified by others) then they'll maybe think about what to put there.
I maintain that the very best way to use the sandbox is to identify the things that are absolutely forbidden (non GPL code, non Drupal stuff, dangerous or subversive code etc.), and let the people using them decide what the best use is. People are innovative and creative.
People are also lazy. This is immediately obvious from the current state of the sandboxes. What we want is to encourage collaboration. This is not advanced by hiding stuff in sandboxes. Even if your pre-alpha code in /modules is crap but ut expresses a great idea there might somebody see it and contribute to or take over development. This is not likely to happen in sandboxes becasue nobody looks at them unless pointed to a specific file. Cheers, Gerhard