#include <hallo.h> * Nikita V. Youshchenko [Mon, Oct 25 2004, 12:17:15AM]:
> In fact, existance of testing allows me to be a user and a developer at the > same time. > > You may state that such reason has nothing to do with release process, for > which testing was originally proposed. Yes, I agree. However, the above > argument shows why testing *is useful for real life* even in it's current > state. Let's assume that I agree with you, for a moment. > As for role of testing in the release process, I believe there is plenty of > room to improve. Yes, a lot. > You write, biggest problem with testing is outdated packages. Yes, probably > you are right. So, some action should be taken to overcome that. I can't > immidiatly answer what exact actions will help, but it's a good direction > to think on. Let's try. > So what makes package's path to testing long? > - - RC bugs. Here nothing else could be done other than fixing the bugs. > Personally I thing that some infrastructure change could be useful here to > force maintainers fix RC bugs. Probably any RC bug without activity for I already collect some ideas about creating an anti-karma list. Listing maintainers that keep real bugs open for a while (based on the impact; Severity: normal and above for all packages, minor for Section: standard++ packages), multiplied with the time they have existed and summ'ed over all packages. The results would be quite interesting, I expect even some "core" developers among the crap-producing part. > several (say, 5) days should "become more public", some mechanism should > be used to encourage non-maintainers to work on the issue. Okay. This could be done with the wnpp listings on d-d-a sorted by the impact of the bugs. > - - Complex dependency chains. Probably some scheme could be used to decrease > the effect of those. E.g. build mostly against testing, not against sid, > and use build-deps from sid only if relly required (what exactly "really > required" means here, should be defined separately). This is another thing I have proposed a solution, a while ago. Many maintainers use Build-Depends to control transitions in Sid, while this implicitely breaks Testing transtion. There should be a Build-Depends-Min: field where the oldest required version of libFoo is listed. So t-p-u autobuilders could pick this minimal set of Build-Dependencies which is sufficient and would make Testing transition possible without having the binary transition. Yes, there are problems based on ABI incompatibilities that could be hidden with this method, but that is the price for having working build-debs and sane transtition times (in average). IIRC a quarter of Testing cannot even be built based on Testing Build-Deps. And the last part is not hidding open bug reports as we currently do (Sid packages close bug reports that still exist in Testing/Stable for months/years, months after that). I was told that the needed code for the BTS is almost ready and they just wait for the release to activate it. > > But many maintainers simply do not care much > > about testing, Unstable runs fine for them. > > Do you really think that this is the point? Do you have statistics? No, but some web survey can surely be done. There is something on http://www.debian-administration.org/?poll=3 but there are not enough votes (IMHO) base any statement on it. Regards, Eduard. -- Jede einem Menschen zugefügte Beleidigung, geleichgültig, welcher Rasse er angehört, ist eine Herabwürdigung der ganzen Menschheit. -- Albert Camus
