Joey Hess <[EMAIL PROTECTED]> writes: > However, out of all the packages with Vcs-* fields, only about 400 (20%) > don't use alioth. If maintainers going MIA and taking their version > control repos with them becomes a problem, we could proactively mirror > those onto alioth. A mirror that only ran when a new version of a > package was uploaded shouldn't generate too bad load, especially for the > ones already using distributed systems.
For whatever it's worth, I agree that you're probably significantly undercounting the number of packages using a revision control system, since unless the VCS is public, there's no point in using the Vcs-* fields. For example, every Debian package I maintain is maintained in a VCS, but many of them are maintained in Stanford's internal Subversion repository, so Vcs fields are pointless at present. I don't think the use of a VCS implies what it seems you believe it implies, but that's a different matter. Having the repository on alioth doesn't necessarily help if you're talking about something like Subversion (and particularly CVS) depending on the use case. I don't think we really get back the functionality of quilt until we're shipping the repository with the source package. Having access to a read-only Subversion repository doesn't really help with merging local patches into new upstream releases, for example (something that I have to do all the time, and which is *way* easier for packages that use quilt or dpatch to the point that I've had to convert Debian packages that don't use either to use quilt just to be able to deal with them). -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
