Deprecated - Drupal.org infrastructure

hi,

i can't see instructions for how to check out drupal cvs anonymously.

i downloaded the drupal cvs tar ball, but it seems to be an export, so i can't update it.

any help much appreciated.

cheers
justin

During the CVS Access request process, one of the questions was I will only commit code that is licensed under terms of the GNU public license Yes/No. I answered Yes, and have problems with this requirement, but some clarification would be appreciated.

The mailing list archives haven't been updated since November 8th. What's going on?

When you go to Modules/cvs, what modules do you get listed?

(a) The ones which are compatible with the latest cvs version of Drupal.
or
(b) The latest cvs versions of the modules, usually compatible with the version of Drupal that was the current one when the modules were lastly modified.

(sorry for the complicated sentences, but I just want to find the truth :) )

Please understand that my intention is not to start a flame war or a blame fest, but just to offer a constructive suggestion. As a non-technical user, I am constantly stumped (and I believe I am not alone) by two things I consider as the most serious usability issues on drupal.org:

1.) Tagging the tar balls of contrib modules by their original release date instead of the last update
2.) Requiring to manually apply patches

As far as 1 is concerned, one or two authors go out of the way to help newbies avoid confusion by mentioning the date of the latest release. Acidfree, for instance, has the following message on its project page:

Attention — last packaged 09 Nov 2005 05:10:00
The listed 'release date' below is a little off. The tarballs below were really repackaged on the above date/time despite the link text below.

But, really, drupal.org should be doing this automatically. Is it so difficult to do this?

As for 2 above, is it again difficult to provide the patched module for download? I know that issues are sometimes reopened even after a code review has been done, but the taxonomy patch (there are at least four forum postings right now about this issue) is a good example of an instance where the module has not been patched even months after it was accepted.

Ideally, 1 and 2 above should work in tandem so that when a module (core or contrib) is patched, it automatically makes it to the tar ball without requiring users to manually patch them. I suspect it happens for core modules (gets incorporated into the drupal download perhaps?) but not for contrib.

What would it take to categorize the available modules somehow? It's not very efficient to read over the entire alphabetical list looking for something appropriate to our needs. It would be much more helpful if we could look under "menuing" and "image handling" and "events", etc.