"Thaddeus H. Black" <[EMAIL PROTECTED]> writes: > [Not private. Reply on-list if you wish.] > >> However, I do think that not including amd64 (while keeping mips and >> friends) in the sarge release due to mirroring problems is ridiculous. > > Amen, brother. > >> ... packages are uploaded too frequently, ... > > How often is probably too often, in your view? (This is just a > question. I happen to keep a package which uploads irregularly ten or > fifteen times per year.)
Short answer: As long as your package is a candidate for testing (and you feel is generally fit for testing) but is being blocked by something else, you should probably wait to upload until the current version makes it into testing. How often is that? Well... Consider package 'foo', which has either a direct or indirect relationship with 50 other packages in Debian (it depends directly on a few packages, those packages depend on other stuff, and some packages depend directly on foo, etc.). And say it's being blocked from testing because some package in there is broken. How do you get all of these into testing? You have to fix the broken package, and have all of the interrelated packages become simultaneously eligible for inclusion in testing. Since there's a constant churn of packages in unstable, probably someone will upload some package in chain, which means all of the others will have to wait for it. Or someone uploads a new upstream release, which turns out to be too buggy. Then all of the packages have to wait for that one to get fixed. In general, it would probably work best for testing if an upload turns out to be free of RC bugs that the maintainer doesn't touch it for a couple months. Of course, we're all volunteers and maybe in a couple of months the maintainer won't have time to do another upload. But he or she has time now, so why not just do it now? And, without any kind of established release timeframe, maintainers don't generally know if it's best to wait on an upload or just do it right away. For example, if a maintainer decides it's best to wait until the next release to make a big packaging change because the release appears to be near, more than likely that maintainer will be sitting on their hands for 6 months before they finally realize, hey, we're not actually going to release soon. So they make the upload, break some stuff, and generally push back the release even more. I don't think overly frequent uploads are the real problem. I think the more significant problems are: 1. Package dependencies are too complicated and interrelated. 2. Library shlibs are too tight. 3. The overall discontent with our releases taking too long make some of the general developer population disinterested with the release, and thus don't take proper care to ensure their packages are entering and working in testing. The newer libtool versions are definitely helping with (1), though only to an extent. Modern software is just getting very complicated and is using lots of libraries. Unless we throw out things like GNOME and KDE, there's really no way around it. (2) is definitely something that needs work. It seems like every library package out there is just using 'dh_makeshlibs -V', and that's unfortunate since the dependencies produced are in most cases overly tight. As for (3), well, that's been a known problem for years and no RM has yet figured out how to motivate the troops. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
