Hi. (I first submitted this question to debian-testing, but was referred here for discussion.)
I have been looking at the "excuses" page[0] and was struck by how very old some packages are in testing, yet only the very latest bleeding edge version from unstable appears to be considered for inclusion. Am I misunderstanding something, or does this approach "punish" projects that adhere to the Open Source motto to release often? Hypothetical example: Project X makes an effort to prepare a solid release, squashing all RC bugs and making sure each target builds flawlessly. They pack it up, label it "3.0" or whatever and release it. The package goes into unstable and, being a non-critical update, needs 10 days to become a "Valid Candidate"[1] for testing. For a while, people have been working on a big patch to move project X from gnome to gnome2. This was submitted to the project but was delayed until after 3.0. Now that 3.0 is out the door and the users have a stable version to work with, the gnome2 patch goes in and a new version, 3.1, is released only a few days later. This version is not a valid testing candidate, since gnome2 is not yet included in testing, but it's a welcome update for those running gnome2/unstable. Now the catch: Since the testing scripts only consider the latest unstable version, the testing-ready 3.0 version is never considered. Instead, the 3.1 version is rejected (due to depending on gnome2) and the old 2.0 version is kept. Is there a good reason for this? Would it not be better to track all versions of a package and include the latest (if any) that fulfills all requirements? It seems to me that the current system leaves testing with older versions than necessary. Note that I'm not advocating relaxing the inclusion criteria for testing. I am just asking why they are not applied equally to all versions. [0] http://ftp-master.debian.org/testing/update_excuses.html [1] http://www.debian.org/devel/testing -- Björn
