Deprecated - Drupal.org infrastructure

I was somehow dismayed at Robrecht Jacques CVS message [1] that he had removed his work on the image module from the sandbox. Apparently he was in violation of the sandbox rules (#6, in particular). It made me wonder, who else is in violation? I think lots of people are. Would JonBob's CCK module be in violation of this "no module, not in core, has to be a patch" nonsense? Patches generally get attached to issues, don't they? Why keep patches in the sandbox? And why force all module development to take place at the project level?

People expect that projects are ready to be downloaded and tested; that they've at least passed the basic "beta" stage of functionality. Are we really better off if Robrecht Jacques develops his image module ideas offline? What if I want to look and see what he's doing? Now I have to email him.

Here are the sandbox rules. Please dissect them and see if they make any sense based on how we develop these days.

1. Always document your changes.
2. Split different set of patches into different directories. It takes longer to find the set of files relating to one change if it is mixed in with 2 other patches.

Just tonight I noticed that I'm not able to:

I would appreciate insight into exactly how Drupal.org integrates with mailing lists. I am looking for the ability to transparently integrate a mailing list with Drupal forums, etc. without requiring members to create an account / manually subscribe to a list manager. I know there are a number of modules that do this to varying degrees available, but I would appreciate a concise description of exaclty how Drupal.org has accomplished this feat. Requirements include:

I am sure that the new infrastructure is still being tweaked but is anyone else been having significant problems accessing the site the past few days? Page loads are averaging over 2 minutes no matter whether I am accessing drupal.org from home or work. Often I get timeouts.

FYI, about 10 minutes ago, while at http://drupal.org/node/288, I clicked on the "cron page" link to http://drupal.org/cron.php, and received the following error.

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 35443 bytes) in /home/www/drupal.org/includes/database.mysql.inc on line 93

I know there was some talk a while back about having BugDays on Drupal. I don't know if that's still the plan, but I wanted to get the ball rolling and discuss why and how it would be organized so we can get something started sooner than later. I was, for a short while, running bug days for CivicSpace until we went out of our way to move all of our code to drupal.org where the volume of feedback and patch submissions were much greater. What's written below are simply my thoughts around it. I'm open to feedback on these ideas, though ultimately, I would like to leave the details up to whoever ends up as the designated coordinator(s) for a Bug Day.

Why have a bug day?
---
Well, obviously, the Drupal project has been growing and growing. As such, we need to do something towards the end of organizing and fixing our bugs in a way that is efficient and optimal, while keeping in mind that this is mostly a volunteer effort (as most Drupal coders work on a volunteer basis).

In my own view, Drupal core is relatively stable and already has enough talented programmers scrutinizing the code base. What I personally would like to see is more attention being given to the contributed modules. Contributed modules often have a problem with correctly making use of the Drupal API and are more privy to slacking on code conventions. This is expected since a CMS engine as flexible and fast as Drupal will inevitably pose a steep learning curve to those that want to add new functionality. And often, the rush to add new features is understandably more urgent to the implementor than the desire to be vigilant about API usage and coding standards. However, if Drupal is going to take over the world, it will be through its rich variety of contributed modules. Most of the CMSs out there offer the same features that Drupal core offers; the magic, in my opinion, is in the contributions. However, the contributions need to be just as stable as the core. Otherwise, the projects page, which lists 160 or so modules, will be a deceivingly long list.