Re: Packages preventing other packages from going into testing (fwd)
On Mon, Jun 16, 2003 at 10:58:09PM +0200, Jacob Hallén wrote: My program answers the question Where will an extra effort produce drastic results? I'm sure I could have modified Björns program to yield this output, but I don't read and write Perl programs for pleasure. http://bjorn.haxx.se/debian/stalls.html ? -- Peter Mathiasson, peter at mathiasson dot nu, http://www.mathiasson.nu GPG Fingerprint: A9A7 F8F6 9821 F415 B066 77F1 7FF5 C2E6 7BF2 F228
Re: Packages preventing other packages from going into testing (fwd) (fwd)
Peter Mathiasson wrote: On Mon, Jun 16, 2003 at 10:58:09PM +0200, Jacob Hallén wrote: My program answers the question Where will an extra effort produce drastic results? I'm sure I could have modified Björns program to yield this output, but I don't read and write Perl programs for pleasure. http://bjorn.haxx.se/debian/stalls.html ? No, this list contains all stalled packages, including the ones that depend on packages that are too young to go into testing. They are uninteresting from my perspective, because the work they needed has already been done. I'm not claiming that solving these problems will solve all problems, but the top of my list are the most urgent ones (from a pure package perspective). Other problems will surface once these are solved, and this is indeed why these things are the most urgent ones. Before they are solved the other problems will go unnoticed. The key to better performance in producing new Debian versions is not necessarily in people doing more work, but in reducing cycle times. The earlier a problem is noticed, the earlier it can be fixed. The earlier you discover that your bug is holding up everything else, the earlier you will get to it. Jacob Hallén
Re: Packages preventing other packages from going into testing (fwd) (fwd)
Looks like your KMail is doing strange things with the In-Reply-To header (using a wrong Message-ID). Your last mail contains: In-Reply-To: [EMAIL PROTECTED] In reply to: Message-ID: [EMAIL PROTECTED] Ie you break all threads you are replying to. Christophe -- Christophe Barbé [EMAIL PROTECTED] GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Dogs come when they're called; cats take a message and get back to you later. --Mary Bly
Re: Packages preventing other packages from going into testing (fwd)
J.H.M. Dassen (Ray) wrote: On Sun, Jun 15, 2003 at 18:44:12 +0200, Jacob Hallén wrote: I have written a little Python program that analyses http://ftp-master.debian.org/testing/update_excuses.html to find out where the bottlenecks are for packages going into testing. Essentially, it is a count of packages that directly and indirectly depend on a package with at least one RC bug before they can go into testing. Maybe I'm missing something, but it looks like you're reinventing http://bjorn.haxx.se/debian/ Yes, you are missing a small but important thing. Björns program is designed to answer the question Why is package X not in testing?. It does this very well and has lots of nifty features I didn't put into mine. My program answers the question Where will an extra effort produce drastic results? I'm sure I could have modified Björns program to yield this output, but I don't read and write Perl programs for pleasure. I think it is important to have a tool that answers my question and does so in a terse form that is pruned of all irrelevant data. If Testing is much closer to resleasable than it is now, it will be so much easier to make decisions about what to do with the few packages that are not ready for a release and so much easier to make a time plan for when to release. I know that releases are made when everything is ready, but this still means that some packages have to be dropped from the release and you have to make an extra effort for some time (bug squash parties etc) before a release is possible. Having luked on the Debian lists for many years, I think the next release will be more of a challenge than any of the earlier ones. Too few of the developers are really focused on what it takes to make a release. If there isn't change, I'm not sure there will ever be another stable release. Jacob Hallén
