Register all core modules/APIs on drupal.org

Hmmm. I'm not sure. I think people might actually find this really confusing, expecting to find a download tarball there for the module, like every other module.

I also worry about other projects doing this same thing, when they are a package of multiple modules. For example, separate nodes for Views, Views UI, Views Export module even though "Views" is the only thing with a download page.

I lean towards won't fix, and simply adjusting the Drupal core project page to links to the information you feel is missing.

I agree with webchick that this is a "won't fix". I don't see what issues this would solve, and I think it would cause many more.

And we definitely don't want a separate "project" for each sub-module within a project, in my opinion.

However, since each sub-module and each module within core does have its own .info file, we could potentially create a registry of all core and contributed modules on drupal.org, which would link you to the project page (either Drupal or a contributed module). That could be useful...

Crazy crazy long-term thinking: git supports "sub-modules" that are pulled from another git repo but integrated into the current repo. That means it's theoretically possible to maintain core modules as separate projects but integrate them in via git.

It would potentially complicate the workflow, so I don't know if that's a good idea, but I throw it out to cause trouble...

Let's move this into the issue queue for d.o webmasters, since this would not be something we would do in Drupal source code, or that is confined to Drupal core source code.

Note that http://drupal.org/project/contact deliberately exploits a name collision in order to provide a drop-in replacement for core's contact.module...

hah, you can add

http://drupal.org/project/filter
http://drupal.org/project/form

to that deliberately-exploits-name-collision list. ;)

Note that you already need to have an issue follow-up template ready to paste in such projects, because some users don't grok that these are separate projects.

However, Crell is right in that a fully-fledged spin-off of modules into projects would make sense in the long run. Also solving the MAINTAINERS.txt issue in the long run.

And yes, this could work out: http://drupal.org/project/node ;)

However, http://drupal.org/project/statistics and http://drupal.org/project/user does not. :)

:P

oh, I forgot. http://drupal.org/project/translation also belongs in that intentional-exploit list.

Closing old, stale issues as part of the webmaster's clean-up spring of DrupalCon Prague.