project shouldn't publish/unpublish nodes automatically based on releases

i think this whole buisness of the project module trying to publish/unpublish project nodes based on release tarballs is a) buggy and b) backwards. here's how i think it should work:

1) contrib authors add their code to an available directory in CVS
2) author submits a project node pointing to their directory
3) site admin reviews the node, decides if it's a fork/duplicate, or worthy. assuming it's good:
4) site admin publishes the node (* this should be the _only_ way a node gets published)
5) now author has ability to branch/tag their code
6) based on branches/tags, project module creates appropriate tarballs (also see http://drupal.org/node/58066)
7) based on existance of tarballs, project module adds download links

i think it's wrong that the existance of the tarballs determines if the node gets published or not. a) it's entirely reasonable (at least not on drupal.org) for project nodes to be published that don't have a physical release associated with them. furthermore, if project is going to automatically make a "cvs" tarball for each project (which i'm also not sure is a good idea, seems like module authors should have to specify somewhere that they think their module works against CVS head and it's worth generating a tarball), then this whole access control workflow is broken. as soon as the author commits their code and so much as applies for a project node, the "cvs" tarball will get made, and that will publish their node, without any admin intervention. (at least, that's how i understand what's going on based on comments from killes and nedjo, not based on testing or reviewing the actual code).

honestly, if we rip out all the auto-publishing code, i think the project workflow will be cleaner, the CVS access integration will make more sense, and we might just solve all these evil bugs where projects mysteriously disappear (e.g. vote_up_down, etc).