Seems I need to take sandbox in my own hands
Hi, If this sandbox rule is not changed really soon then I will simply open a Project Team account at cvsdude.com and pay the monthly thirty two dollars out of my own pockets if need to be. This account has 5 Gigs of disk space and Unlimited Authorized accounts and Unlimited Monthly transfer -- it's aplenty for our purposes. Interested parties, please contact me. 329 dollars is the yearly fee, cheaper and once paid, we have a full year regardless of what happens. I hope I will get at least the permission to include our link in the handbook here and there. Regards NK
Karoly Negyesi wrote:
Hi,
If this sandbox rule is not changed really soon then I will simply open
The rules haven't changed, they are only enforced. The only inconvenience to users is that they'll need to tell us to re-enable their access in case they were using the sandbox for core development. These are only very few people, unfortunatly. Stop acting silly. Cheers, Gerhard
----- Start Original Message ----- Sent: Sat, 16 Dec 2006 15:44:46 +0100 From: Gerhard Killesreiter <gerhard@killesreiter.de> To: development@drupal.org Subject: Re: [development] Seems I need to take sandbox in my own hands
Karoly Negyesi wrote:
Hi,
If this sandbox rule is not changed really soon then I will simply open
The rules haven't changed, they are only enforced. The only inconvenience to users is that they'll need to tell us to re-enable their access in case they were using the sandbox for core development. These are only very few people, unfortunatly.
Stop acting silly.
I can not take an oath that every code I commit to my sandbox is intended for core. Some of the examples I mentioned -- JonBob's node access modules, our memcached session work -- definitely was and will not be for core. Further research shows that http://www.csoft.net/budget-vhost.html has unlimited CVS/SVN sub accounts for 15 bucks per month. This is even better. I will open the account on Monday or Tuesday. Regards NK
Quoting Karoly Negyesi <karoly@negyesi.net>:
Further research shows that http://www.csoft.net/budget-vhost.html has unlimited CVS/SVN sub accounts for 15 bucks per month. This is even better. I will open the account on Monday or Tuesday.
Cool. I'll give you access to CVS or SVN for $5 per month, SF will do it for free. 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
Hi, I know that you want the sandbox accounts to say the way they are, and you are willing to pay to get this. Do not pay for this, I am willing to set up a cvs hosting with my host company, and provide this service to anyone that wants it. I have Gb of space that can be allocated, and TB of bandwidth that can be donated to this. I can hand out most likely more that enough user accounts. I think this is a bad change/enforcement of the policy for sandboxes, and that the current system is a very valuable resource. I know that the sandboxes are no longer really used for their original purpose, but their use to a great help to development and share early code. 1 idea I did have is to move the sandbox to a 3rd repository, and we will not have the chaos of the sandboxes in the contrib repos. Gordon. Karoly Negyesi wrote:
----- Start Original Message ----- Sent: Sat, 16 Dec 2006 15:44:46 +0100 From: Gerhard Killesreiter <gerhard@killesreiter.de> To: development@drupal.org Subject: Re: [development] Seems I need to take sandbox in my own hands
Karoly Negyesi wrote:
Hi,
If this sandbox rule is not changed really soon then I will simply open The rules haven't changed, they are only enforced. The only inconvenience to users is that they'll need to tell us to re-enable their access in case they were using the sandbox for core development. These are only very few people, unfortunatly.
Stop acting silly.
I can not take an oath that every code I commit to my sandbox is intended for core. Some of the examples I mentioned -- JonBob's node access modules, our memcached session work -- definitely was and will not be for core.
Further research shows that http://www.csoft.net/budget-vhost.html has unlimited CVS/SVN sub accounts for 15 bucks per month. This is even better. I will open the account on Monday or Tuesday.
Regards
NK
!DSPAM:1000,45840d95166526732721593!
If I'm understanding correctly, the point is not "Don't do what you've been doing in sandboxes," but rather "Do it in the /contributions/modules directory instead, it's better there". As folks have pointed out, the sandboxes have served a valuable role for contrib modules. As developers, many of us have used our sandboxes as places to work up experimental code. We have benefited from access to others' code. But do we need to do this particularly in sandboxes? The use of sandboxes for developing code valuable to the community has had some costs, e.g., multiple versions of the same module (not clear which one is current), obsolete code not deleted when a newer version is in contributions/modules, loss of CVS history when code is moved, etc. Personally, I've used my sandbox because I hesitate to put code in the 'sacred' /contributions/modules directory. What I'm hearing is, don't worry so much. Starting an experimental project, not yet (maybe never) ready for distribution? Go ahead, create a new directory at contributions/modules and do it there. Not ready for download? Simple, just don't create a project - yet - on drupal.org. Only people doing CVS browsing or checkouts will see it. All developers will have CVS write access to the directory (just like has always been the case for sandboxes), so you can collaborate. Experiment to your heart's content. Later, you can always delete the project, or create a drupal.org project for it if/when it's ready, or request to have it moved elsewhere (e.g., into an existing project's directory, if it's meant as part of that project). Look through the /modules directory right now and you'll find plenty of directories like this. So, I'm thinking, we're not really losing anything. We're just going back to how it was always supposed to be: develop new code in its place, rather than in a sandbox. As an added bonus, we won't lose CVS history for projects. In general (CVS maintainers, please correct me if I'm wrong), we can summarize the message as "The contributions/modules directory, rather than sandboxes, is the right place for (experimental or otherwise) code for contrib modules".
can summarize the message as "The contributions/modules directory, rather than sandboxes, is the right place for (experimental or otherwise) code for contrib modules".
But this will not answer the need for mfredrickson's vews patches , and other experimental code that is not even meant to be released ever. To answer Steven's concerns, his starting "If you used the sandbox before simply as a means of revision control," is false. These code often are not version controlled because they see only one commit. Which words of I am using the sandbox to share my experimental code with the Drupal community can not be understood? The userstag module I checked in 2005 autumn and was contacted maybe a month ago by someone who needed it and ported it to 4.7. More on Steven's letter: "many developers now have personal revision control systems, either hosted or distributed" -- yes, distributed, hard to reach, not on Drupal's infrastructure.
The sandbox as it is now is one big pile of code... mostly crap, with some active pieces buried in it.
Yes! It is! Keep it so! To use the words of Tolkien: "All that is gold does not glitter". Who can say what's crap and what's not? Do not even bother. Regards NK Ps. If you think I am frustrated, I am not. I am only sad.
On Sun, 17 Dec 2006, Karoly Negyesi wrote:
I am using the sandbox to share my experimental code with the Drupal community
As someone who uses his sandbox to share a theme (the admin part of the civicspace theme as a standalone theme) and a module (Heine's switchlang module as one of the starting points for i18n collaboration), I am said to see the sandboxes disappear. I will certainly not make a project out of these stuff. Someone will need to find the time again to extract the admin theme out of the civicspace theme and replicate my fixes if need be, since my code will not be available as a starting point. Heine's switchlang module is not available anywhere else AFAIK, and it is certainly not for end user consumption, so it will just simply vanish. I think this is done against the community, and is not one of the christmas presents I expected, but if this needs to be done, then so be it. Everyone will need to find their own ways to collaborate on "not-(yet)-for-end-users" projects, since drupal.org does not seem to provide this community support anymore. Gabor
In the sandbox discussion, an interesting pattern has appeared. Virtually every developer who is involved with Drupal.org infrastructure at a personal level (those named in the title) want to bring order to the sandboxes and crowbar the "not projects" that live there into the new release system. Everybody else is against this. Worse, we don't seem to be moving towards agreement. 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. The answer can't be "the code there is lousy" because that applies to at least 200 of the projects in contrib as well (a number which will rise with the new proposed changes). So what is it that makes the sandboxes a thorn in the side of the people who actually have to maintain the infrastructure? 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. cheers, Robert
Robert Douglass wrote:
In the sandbox discussion, an interesting pattern has appeared. Virtually every developer who is involved with Drupal.org infrastructure at a personal level (those named in the title) want to bring order to
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...
the sandboxes and crowbar the "not projects" that live there into the new release system. Everybody else is against this. Worse, we don't seem to be moving towards agreement.
I am not that pessimistic. Most people seem to understand now that module development should be in /modules.
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?
The answer can't be "the code there is lousy" because that applies to at least 200 of the projects in contrib as well (a number which will rise with the new proposed changes). So what is it that makes the sandboxes a thorn in the side of the people who actually have to maintain the infrastructure?
Kjartan has explained that quite well. As far as I see it there are the following use cases for sandboxes that don't fit the current rules: - share some code snippet (Karoly, Goba) - develop patches for contrib modules 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.
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. And most of the stuff is crap that nobody will understand, ie is completely undocumented and thus unusable by anybody but the author. Example: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/yched/ I initially was delighted to find this, because there is some nodereference issue I need to get resolved. But what am I supposed to do with this? "Fisrt test commit :-)" is not a useful commit message and the README is only the original. Most of the other sandboxes are similar: Undocumented, non-working, age-old stuff. 98% inside these sandboxes is crap not worth keeping. Cheers, Gerhard
[snip] On Sun, Dec 17, 2006 at 01:58:07PM +0100, Gerhard Killesreiter wrote:
As far as I see it there are the following use cases for sandboxes that don't fit the current rules:
- share some code snippet (Karoly, Goba) - develop patches for contrib modules
I have another case. I'm maintaining a copy of the bidi.module in my sandbox (http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/msameer/) Why isn't it a drupal project ? For 2 reasons: * The code is ugly and I don't have enough time to clean it and fix the coding style. * I'm not interested in maintaining an _official_ drupal module. I just keep it in my sqndbox and fix whatever whenever I find enough time. I always ask people to get it from my sandbox and to monitor it for changes. I'm sure we can find more use cases if we investigate farther (Although I understand that people keep -what we consider in our opinion to be- crap) All the best, -- GNU/Linux registered user #224950 Proud Egyptian GNU/Linux User Group <www.eglug.org> Member. Life powered by Debian, Homepage: www.foolab.org -- Don't send me any attachment in Micro$oft (.DOC, .PPT) format please Read http://www.gnu.org/philosophy/no-word-attachments.html Preferable attachments: .PDF, .HTML, .TXT Thanx for adding this text to Your signature
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. By putting it in my sandbox I am deliberately saying "Beware! The odds of this code being crap are 98/100" > As far as I see it there are the following use cases for sandboxes > that don't fit the current rules: > > - share some code snippet (Karoly, Goba) > - develop patches for contrib modules > > 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. >> 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. 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?" > 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. 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. cheers, Robert
There is an elegant semantic difference in my mind between /modules and /sandbox. But I guess nedjo is quite right, maybe I've been too precious not wanting to clutter up contributions/modules! FWIW, my example is: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/sime/casetracker_... I have been developing this in parallel to casetracker and I haven't put it in /modules because I would like one day to see it included in casetracker. I am not a maintainer of casetracker, so obviously it's not me making the decision, so I'm happy to cruise for a while and developing this in my sandbox really makes sense to me. .s
sime wrote:
There is an elegant semantic difference in my mind between /modules and /sandbox. But I guess nedjo is quite right, maybe I've been too precious not wanting to clutter up contributions/modules!
FWIW, my example is: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/sime/casetracker_...
I have been developing this in parallel to casetracker and I haven't put it in /modules because I would like one day to see it included in casetracker. I am not a maintainer of casetracker, so obviously it's not me making the decision, so I'm happy to cruise for a while and developing this in my sandbox really makes sense to me.
Perhaps there is some value to the argument to clean up the sandboxes a little because i was busy writing a module that duplicates this functionality nearly exactly. This Plus the ability to organize your cases into order you plan on working on them. Thank you for pointing this out. -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
On Dec 17, 2006, at 9:17 AM, Michael Favia wrote:
I have been developing this in parallel to casetracker and I haven't put it in /modules because I would like one day to see it included in casetracker. I am not a maintainer of casetracker, so obviously it's not me making the decision, so I'm happy to cruise for a while and developing this in my sandbox really makes sense to me.
Perhaps there is some value to the argument to clean up the sandboxes a little because i was busy writing a module that duplicates this functionality nearly exactly. This Plus the ability to organize your cases into order you plan on working on them. Thank you for pointing this out.
*sigh* so, we've got: - project_issue.module - casetracker.module (official) - casetracker_work.module (sandbox - sime) - casetracker_fork_2.module (??? - michael favia) - CCK-based project/issue tracking (http://groups.drupal.org/node/409) - helpdesk (pre-alpha, i think) - ... absolutely *none* of these is actually full-featured and does what we want. i've been working hard making project_issue.module better, and morbus has been beating casetracker (official) into submission (IMHO, a tragic fork of resources right there). yes, choices are good. yes, 1 giant module that does everything won't make everyone happy. however... <desperate plea> instead of forking our limited development resources in this crucial space, can't we collaborate more? all the things you hate about project_issue (and i'm sure there are many), let's just fix them so it works how we all need, instead of starting over from scratch for the (N+1)th time... pretty, pretty please: join the issue tracking group: http://groups.drupal.org/issue-tracking-and-software-releases collaborate, don't fork... </desperate plea> thanks, -derek
*sigh*
That sounds like the sigh of incorrect assumptions! casetracker_work.module and favia's similar do /not/ duplicate casetracker or project_issue. If anything, they duplicate timesheet, timelog, and other time management modules (none of which I actually think are of any high quality, personally).
morbus has been beating casetracker (official) into submission (IMHO, a tragic fork of resources right there). yes, choices are good. yes, 1
We've already had this discussion a thousand times. -- Morbus Iff ( accept no prostitutes ) 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
http://groups.drupal.org/issue-tracking-and-software-releases
I never joined this before because it seemed far too software + release entwined. My needs for casetracker (and the original needs of those who created it, being DaveNotik and his team) are much more generic. Granted, we've had THIS particular discussion before too. I'll join it now. -- Morbus Iff ( morbus == grumblestiltskin ) 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
http://groups.drupal.org/issue-tracking-and-software-releases
You nail it /right/ on the head: ------------------- http://groups.drupal.org/node/409#comment-1208 I'm just coming at this from the slightly bitter point of view that the project.module, for better or for worse, is the fundamental module that sits on top of drupal core to make drupal.org (and therefore drupal itself) possible. it's how we deal with the software development process for our entire system. i'm feeling a little embattled, like i'm the only one who actually cares enough when it's broken to stay up until 3:30am to make sure killes updates the copy on drupal.org with the fixes i made ------------------- This is /exactly/ the reason that another project management system has to exist. Any time a single and masterful use case (such as d.o) drives a piece of software (like Ruby on Rails for Ruby), bad things happen: development slows, innovation slows, and walls grow. The module caters more and more to the needs of the One then the needs of the Many. -- Morbus Iff ( morbus == grumblestiltskin ) 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
On Dec 17, 2006, at 10:37 AM, Morbus Iff wrote:
That sounds like the sigh of incorrect assumptions!
you betcha. ;) i didn't audit any of the above mentioned code, i was just going from what i saw in the emails...
The module caters more and more to the needs of the One then the needs of the Many.
which is exactly what i've been working hard trying to undo since i took over maintaining project*. it's still a work in progress, but it's *much* more useful to other sites now... and, yes, we've had this discussion before, and i've (partly) resigned myself to at least project vs. casetracker. however, IMHO, we don't need 4 more... -derek
Derek Wright wrote:
and, yes, we've had this discussion before, and i've (partly) resigned myself to at least project vs. casetracker. however, IMHO, we don't need 4 more...
I think that a hybridization of the two (CT + Project) could also be beneficial if we were able/willing to refactor the code management and release aspects of the project module out into new modules. At the foundation i think these two can serve the same purpose from a consolidated foundation with a bevy of associated modules for improved customization for the task at hand. The ability to add code management and release capability, or maybe to disable one mail module and enable another that enables MIME HTML, etc. It would require a small amount of concession from each side but maybe its time to select the best feature sets from each and move forward? As long as we move the useless arbitrary case tracker project numbers to a new optional module im happy. ;). -- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
On Dec 17, 2006, at 1:32 PM, Michael Favia wrote:
I think that a hybridization of the two (CT + Project) could also be beneficial if we were able/willing to refactor the code management and release aspects of the project module out into new modules.
- release management is entirely separate already (project_release.module) - code management is mostly separate already (cvs.module) - the code management separation isn't the most elegant/slick/hook- ful in all of drupal, but it's getting better...
At the foundation i think these two can serve the same purpose from a consolidated foundation with a bevy of associated modules for improved customization for the task at hand.
agreed. this has been my goal all along, and is why project_issue.module is a separate module now, too. again, the separation isn't ideal (and in fact, is currently broken such that if you turn on project_issue, you actually need to enable both project *and* project_release (tee hee) -- but that's an easy fix[1]) but it's getting better, and i'd like to keep moving it in that direction. once D5 porting is done, my next big priorities for project_issue.module are: = convert issue followups to real drupal comments [2] = better OG integration (extending my og_project.moudle) [3] = make it so you can configure what node types should act as your "project" so that you can use project_issue with things other than project.module (much like casetracker already does). [4] basically, define your own CCK "project" type to be whatever you want, and attach a project_issue-provided issue queue to that. = optional views integration [5] (i.e. a separate module we won't enable on d.o, but that exposes issues to views). possibly similar workflow/actions integration add-ons (once i start playing with workflow and/or actions and see if it's worth doing).
The ability to add code management and release capability,
see above, you basically have this now.
or maybe to disable one mail module and enable another that enables MIME HTML, etc.
sure.
It would require a small amount of concession from each side but maybe its time to select the best feature sets from each and move forward?
this is *exactly* what i've been trying to do with the monolithic project codebase for most of the last year. split it up into smaller, more grok-able parts that handle 1 aspect or another, and allow the parts to optionally extend the whole as needed. i'm all in favor of making it so these optional parts could be shared between project and casetracker, if that wasn't going to require massively more work or more ugly code. in many cases, allowing this would probably force more elegant, hook-ful design, instead of project- specific hacks. cheers, -derek [1] http://drupal.org/node/97095 [2] http://drupal.org/node/18920 [3] http://drupal.org/project/og_project [4] http://drupal.org/node/85049 [5] http://drupal.org/node/76725
Hi Michael Michael Favia wrote:
sime wrote:
I have been developing this in parallel to casetracker and I haven't put it in /modules because I would like one day to see it included in casetracker. I am not a maintainer of casetracker, so obviously it's not me making the decision, so I'm happy to cruise for a while and developing this in my sandbox really makes sense to me.
Perhaps there is some value to the argument to clean up the sandboxes a little because i was busy writing a module that duplicates this functionality nearly exactly. This Plus the ability to organize your cases into order you plan on working on them. Thank you for pointing this out.
That's great to hear, if you have any collaboration or compromise ideas I'm all ears. Please follow up here: http://drupal.org/node/98345 I'd like to say, my work was not hidden - it was in the queue and Morbus knows as well. .s
On Dec 17, 2006, at 3:01 PM, sime wrote:
I'd like to say, my work was not hidden - it was in the queue and Morbus knows as well.
sorry, i didn't mean to come off as accusing you of any wrong- doing. ;) i was just making a plea for more collaboration/ coordination via the group i mentioned: http://groups.drupal.org/issue-tracking-and-software-releases thanks, -derek
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
Am 17.12.2006 um 12:34 schrieb Gabor Hojtsy:
As someone who uses his sandbox to share a theme (the admin part of the civicspace theme as a standalone theme) and a module (Heine's switchlang module as one of the starting points for i18n collaboration), I am said to see the sandboxes disappear. I will certainly not make a project out of these stuff. Someone will need to find the time again to extract the admin theme out of the civicspace theme and replicate my fixes if need be, since my code will not be available as a starting point. Heine's switchlang module is not available anywhere else AFAIK, and it is certainly not for end user consumption, so it will just simply vanish.
Same here. I use my sandbox to store my SoC work which is currently in the form of a module rather than a patch. As long as the code is related to Drupal, I don't see a reason why it shouldn't be allowed to be kept there. Konstantin Käfer – http://kkaefer.com/
Konstantin Käfer wrote:
Same here. I use my sandbox to store my SoC work which is currently in the form of a module rather than a patch. As long as the code is related to Drupal, I don't see a reason why it shouldn't be allowed to be kept there.
Because modules go into /modules. Simple as that. There is really no need to hide interesting stuff in a sandbox. Cheers, Gerhard
On Sun, 17 Dec 2006, Gerhard Killesreiter wrote:
Konstantin Käfer wrote:
Same here. I use my sandbox to store my SoC work which is currently in the form of a module rather than a patch. As long as the code is related to Drupal, I don't see a reason why it shouldn't be allowed to be kept there.
Because modules go into /modules. Simple as that. There is really no need to hide interesting stuff in a sandbox.
Gerhard, is there a reason then to litter /modules with alpha quality, not for end users code, or even module like code snippets? As far as I have seen from previous discussions, there was a move to *separate* golden modules from litter (lots of discussions about golden modules and themes repository). Now the hard rule is that we should move litter closer to the golden modules, let it be harder to distinguish. Gabor
Gabor Hojtsy wrote:
On Sun, 17 Dec 2006, Gerhard Killesreiter wrote:
Konstantin Käfer wrote:
Same here. I use my sandbox to store my SoC work which is currently in the form of a module rather than a patch. As long as the code is related to Drupal, I don't see a reason why it shouldn't be allowed to be kept there.
Because modules go into /modules. Simple as that. There is really no need to hide interesting stuff in a sandbox.
Gerhard, is there a reason then to litter /modules with alpha quality, not for end users code, or even module like code snippets? As far as I have seen from previous discussions, there was a move to *separate* golden modules from litter (lots of discussions about golden modules and themes repository).
That discussion was mainly around on how to present those modules to the end user on drupal.org. That is IMO a different topic which can be resolved through the web interface. There is no need to confuse this with the issue at hand which is about the CVS repository.
Now the hard rule is that we should move litter closer to the golden modules, let it be harder to distinguish.
If you consider your module not fit for general consumption, then don't create a release. Cheers, Gerhard
Gerhard Killesreiter wrote:
Konstantin Käfer wrote:
Same here. I use my sandbox to store my SoC work which is currently in the form of a module rather than a patch. As long as the code is related to Drupal, I don't see a reason why it shouldn't be allowed to be kept there.
Because modules go into /modules. Simple as that. There is really no need to hide interesting stuff in a sandbox.
But here's another point; when I check out /modules, I don't want the stuff that other developers don't think I'll be interested in. I want to look into module for tools that are ready to use. I get mad every time I try a contrib module and it is alpha or pre-alpha state. I think "why the hell isn't this in the sandbox, instead of taking up space in my modules directory".
Robert Douglass wrote:
Gerhard Killesreiter wrote:
Konstantin Käfer wrote:
Same here. I use my sandbox to store my SoC work which is currently in the form of a module rather than a patch. As long as the code is related to Drupal, I don't see a reason why it shouldn't be allowed to be kept there.
Because modules go into /modules. Simple as that. There is really no need to hide interesting stuff in a sandbox.
But here's another point; when I check out /modules, I don't want the stuff that other developers don't think I'll be interested in. I want to look into module for tools that are ready to use. I get mad every time I
"Ready to use" is the stable branch of the modules. You just need to check that out and not HEAD.
try a contrib module and it is alpha or pre-alpha state. I think "why the hell isn't this in the sandbox, instead of taking up space in my modules directory".
Your approach to CVS is flawed, I recommend a counselling session with dww. ;) Cheers, Gerhard
On Sun, 17 Dec 2006, Gerhard Killesreiter wrote:
try a contrib module and it is alpha or pre-alpha state. I think "why the hell isn't this in the sandbox, instead of taking up space in my modules directory".
Your approach to CVS is flawed, I recommend a counselling session with dww. ;)
Gerhard, maybe our approach to Drupal.org CVS was formed by previous Drupal.org practice. Common sense was (is) that we put stuff into /modules or /themes, which we intend to release / support in the foreseeable future. This resulted in a perceived level of quality of modules in Drupal.org CVS (even their HEAD version). Now the infrastructure team's policy enforcement tells us that we are free to experiment in the /modules (and /themes) directory, regardless of whether we have an intention to release or support a module/theme. This lowers the bar of the expected quality of the /modules folder significantly. This is at least a big change for many of our minds, and might be possible to respect. Previously: - experiment in your sandbox (anything was allowed including core patches, contrib patches, modules, themes, code snippets) - put "stable" stuff into /modules, /themes, commit to core, etc. Now: - experiment in CVS HEAD in /modules, /themes, etc - it is not possible to collaboratively experiment with core patches, unless you explictly request CVS space for this - it is impossible to collaboratively experiment with contrib patches, code snippets, etc, on drupal.org - release "stable" stuff with branching and tagging your code Maybe it would have been a lot better to show what previous concepts are transforming into. Gabor
Gabor Hojtsy wrote:
On Sun, 17 Dec 2006, Gerhard Killesreiter wrote:
try a contrib module and it is alpha or pre-alpha state. I think "why the hell isn't this in the sandbox, instead of taking up space in my modules directory".
Your approach to CVS is flawed, I recommend a counselling session with dww. ;)
Gerhard, maybe our approach to Drupal.org CVS was formed by previous Drupal.org practice. Common sense was (is) that we put stuff into /modules or /themes, which we intend to release / support in the foreseeable future. This resulted in a perceived level of quality of modules in Drupal.org CVS (even their HEAD version).
"perceived" is quite the right word.
Now the infrastructure team's policy enforcement tells us that we are free to experiment in the /modules (and /themes) directory, regardless of whether we have an intention to release or support a module/theme.
Well, if you already know you don't want to support it, then you are welcome to keep it for yourself. The often advocated idea "but I want to share my code" is quite pointless if the code is unusable.
This lowers the bar of the expected quality of the /modules folder significantly.
This makes it more obvious that there should not be any quality be expected. You read the recent security announcements, did you?
This is at least a big change for many of our minds, and might be possible to respect.
The change in our release system was discussed over half a year.
Previously:
- experiment in your sandbox (anything was allowed including core patches, contrib patches, modules, themes, code snippets)
No, we just did not enforce the existing policy.
- put "stable" stuff into /modules, /themes, commit to core, etc.
Now:
- experiment in CVS HEAD in /modules, /themes, etc - it is not possible to collaboratively experiment with core patches, unless you explictly request CVS space for this
ACK, a rather small hurdle.
- it is impossible to collaboratively experiment with contrib patches, code snippets, etc, on drupal.org
We are discussing this as we speak.
- release "stable" stuff with branching and tagging your code
Yes.
Maybe it would have been a lot better to show what previous concepts are transforming into.
Maybe it would have been, but such is life. Cheers, Gerhard
Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Well, if you already know you don't want to support it, then you are welcome to keep it for yourself. The often advocated idea "but I want to share my code" is quite pointless if the code is unusable.
I would like to point out an actual example where this happened. VotingAPI Field sat in webchick's sandbox "dead" for months. Seeing it I was inspired and a real project was born from those humble beginnings. So I completely disagree that it is pointless, even if the code is unusable as-is. If that code wasn't sitting there on that Friday night when I started, the project never would have happened. Now perhaps this doesn't happen often, and my case is an enigma. However, I seriously believe that this action could kill some useful future projects! Cheers, --fletch
Well, if you already know you don't want to support it, then you are welcome to keep it for yourself. The often advocated idea "but I want to share my code" is quite pointless if the code is unusable.
Stop here. I feel this is the crux of the matter. So say that only code that I want to support is worth sharing. A lot of us want to share code that he does not intend to support. This proves that your statement is false. If we could agree that code can be shareworthy without supporting it then we would be able to move forwards.
Karoly Negyesi wrote:
Well, if you already know you don't want to support it, then you are welcome to keep it for yourself. The often advocated idea "but I want to share my code" is quite pointless if the code is unusable.
Stop here. I feel this is the crux of the matter.
So say that only code that I want to support is worth sharing.
Ok, I should have formulated that better. "If you don't want to support it _and_ it is unusable". What is unusable is obviously in the eye of the beholder, but I think the minimum requirement of anything in either /themes or /modules should be a README which explains what this is about. Cheers, Gerhard
On 17 Dec 2006, at 4:52 PM, Gerhard Killesreiter wrote:
Well, if you already know you don't want to support it, then you are welcome to keep it for yourself. The often advocated idea "but I want to share my code" is quite pointless if the code is unusable.
unusable != unsupported.
I'd like to make an observation without getting into the middle of either the sandbox debate or the version control system debate: Observation: A version control system that provided better support than CVS for actions such as renaming files and directories, or moving a file or subtree from one directory to another, would provide more options (or more workable options) to the sandbox problem. In particular, moving something from /sandbox/mycruftymodule to /contributions/modules/mynewmodule can become an easy, reasonable thing to do. Now I know that there have already been debates over moving off CVS and, if so, which system to move to. I don't know how to make progress on that discussion or avoid it turning into another rathole (as the sandbox debate is rapidly doing). I'm merely pointing this out as a single data point: The sandbox discussion would be different if the version control system were different. I'll let the people who've been through that other debate decide when to reopen it, at which point this debate could be used as a case study. Gary
The sandbox is a good place to do work. People can see the code online, can check it out, can work on it together, and then decide whether to move it to a project. We don't need more Drupal projects. The sandbox is useful and the rules are a hindrance. I'm not proposing no rules, I'm just saying that trying to keep the sandbox a clean and orderly place is silly. What's wrong with having a designated place for chaos? -Robert Bill Fitzgerald wrote:
The rules haven't changed, they are only enforced.
It seems that in this case, enforcing the rules is getting in the way of people doing work --
The other thing that bothers me is the total lack of communication that this would be enforced. I read the devel mailing list. I'm on the d.o and g.d.o. I'm on IRC. The notification that sandboxes had been turned off was the first I heard about it. Thanks for letting us know. I recently had a hard drive crash. Having my sandbox available meant I could get back some patches I had been working on for views. Is views a core module? No. Do thousands of people use views? Yes. Am I a dumbass for not having a better personal back up soluion? Certainly, but my sandbox saved 40+ hours of work on what I hope will be a key views feature. If anyone is using their sandbox for purposes other than bettering Drupal, I will be the first to support ending his/her CVS access. Why punish the rest of us who use it for good purposes? Consider this my request to have my (and everyone else's) sandbox re-enabled. -Mark On 12/16/06, Robert Douglass <rob@robshouse.net> wrote:
The sandbox is a good place to do work. People can see the code online, can check it out, can work on it together, and then decide whether to move it to a project. We don't need more Drupal projects. The sandbox is useful and the rules are a hindrance. I'm not proposing no rules, I'm just saying that trying to keep the sandbox a clean and orderly place is silly. What's wrong with having a designated place for chaos?
-Robert
Bill Fitzgerald wrote:
The rules haven't changed, they are only enforced.
It seems that in this case, enforcing the rules is getting in the way of people doing work --
A sandbox is just that: a play area for collaboration. Restricting it to core patches is unrealistic to say the least. It will hinder code sharing, collaboration, ...etc. Karoly has given examples of why this approach is of value. If this is just enforcing a rule, then the correct way to reevaluate why this rule is there and come out with the best policy for NOW, not just go forward with a decision that may have had valid reasons in the past. Was there any abuse of sandboxes? I am not aware of any having monitored cvs commits for several months. Can we please reconsider/reevalute?
On 12/16/06, Khalid B <kb@2bits.com> wrote:
A sandbox is just that: a play area for collaboration.
Restricting it to core patches is unrealistic to say the least. It will hinder code sharing, collaboration, ...etc. Karoly has given examples of why this approach is of value.
If this is just enforcing a rule, then the correct way to reevaluate why this rule is there and come out with the best policy for NOW, not just go forward with a decision that may have had valid reasons in the past.
Was there any abuse of sandboxes? I am not aware of any having monitored cvs commits for several months.
Can we please reconsider/reevalute?
Note to self: read ALL threads before replying to an old one. Kjartan, thanks for looking at cleaning things up. We need to have policies. Enforcing this one seems retarded to core contributors like chx. Yes, people CAN turn on externally hosted repositories. And, with that, one more use of Drupal.org for collaboration dies. As I said in a previous, older follow up, I opened up a documentation issue for writing up CVS and Sandbox policy. See http://drupal.org/node/103700 I was looking again for other policy stuff like checking in external libraries, etc. (e.g. TinyMCE) and couldn't find anything in the handbook. I created a new policy page we can edit and merge in the contributions/README.txt wording -- see http://drupal.org/node/103704 And +1 to comments on resources....who is this causing a problem for, other than your mental model of what *should* be in our CVS? -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
Quoting Karoly Negyesi <karoly@negyesi.net>:
Hi,
If this sandbox rule is not changed really soon then I will simply open a Project Team account at cvsdude.com and pay the monthly thirty two dollars out of my own pockets if need to be. This account has 5 Gigs of disk space and Unlimited Authorized accounts and Unlimited Monthly transfer -- it's aplenty for our purposes.
If you're really interested in paying money for a sandbox I'll give you access for $5 per month even though I think it would be rather stupid to pay a dime when you have the likes of SF. 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 16 Dec 2006, at 15:32, Karoly Negyesi wrote:
If this sandbox rule is not changed really soon then I will simply open a Project Team account at cvsdude.com and pay the monthly thirty two dollars out of my own pockets if need to be. This account has 5 Gigs of disk space and Unlimited Authorized accounts and Unlimited Monthly transfer -- it's aplenty for our purposes.
I talked to Kjartan and we decided to revert the new policy. The sandboxes should be open again. (Kjartan is currently AFK but he might have more to add tomorrow morning.) -- Dries Buytaert :: http://www.buytaert.net/
On 12/17/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 16 Dec 2006, at 15:32, Karoly Negyesi wrote:
If this sandbox rule is not changed really soon then I will simply open a Project Team account at cvsdude.com and pay the monthly thirty two dollars out of my own pockets if need to be. This account has 5 Gigs of disk space and Unlimited Authorized accounts and Unlimited Monthly transfer -- it's aplenty for our purposes.
I talked to Kjartan and we decided to revert the new policy. The sandboxes should be open again.
Thanks, Dries. Obviously from the discussion that resulted, there are a lot of POV to cover. And most of it was everyone trying to "convince" one or two people with keys in their hands to make these major changes. Might I suggest a little public discussion ahead of time...it kind of feels like folks *knew* there was going to be massive opposition so tried to sneak it in. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
participants (21)
-
adrian rossouw -
Bill Fitzgerald -
Boris Mann -
Dave Fletcher -
Derek Wright -
Dries Buytaert -
Earnie Boyd -
Gabor Hojtsy -
Gary Feldman -
Gerhard Killesreiter -
Gordon Heydon -
Karoly Negyesi -
Khalid B -
Konstantin Käfer -
Mark Fredrickson -
Michael Favia -
Mohammed Sameer -
Morbus Iff -
Nedjo Rogers -
Robert Douglass -
sime