-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> #include <hallo.h> > > * Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]: > > > #include <hallo.h> > > > > IMHO it's somewhat silly to "stop the experiment now" and drop > > testing. Although there are problems with testing, there *are* > > well-known positives of having it. > > All the known positives are outweighted by the negative issues as > described before. I don't think so. For me, existance of testing allows running more-or-less up-to-date systems without facing current development problems with packages/subsystems that I'm not involved in. For a long time, I use mixed (stable/)tesing/sid systems. Most of packages are from testing, sid version is used for a package if testing version doesn't fit for whatever reason. This proved to work very well. I think many developers and technical users do the same, if they don't they should probably try it, because it really works well. 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. As for role of testing in the release process, I believe there is plenty of room to improve. 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 several (say, 5) days should "become more public", some mechanism should be used to encourage non-maintainers to work on the issue. - - 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). - - Arch de-sync. Can't some mix of cross-compilation and more work on toolchain issues improve situation here? I'm currently involved in dpkg-cross, and I see some interesting possibilities here. - - What else? > > Unless such analysis is done, almost any discussion of this topic is > > pointless. Period. > > A-Ha. How long does Testing exists? And why did nobody write this paper > in the meantime? Why do you not try to do so? I describe the facts. Not > some imaginary proof that will never see the daylight. Period. I don't know why nobody did such analysis. (Probably someone did? I'd love to read it!) As for myself, I don't feel I understand the problem deep enough. Although I follow debian developent for many years, I'm only becoming to be involved :). I tried to write something just now, see above. I may try deeper analysis later, however someone with better understanding of details could do that better. > > But such analysis should be done *after* *sarge* *release*. Flaming > > now will only postpone the release and do nothing more. > > As described before, it is too late to stop this discussion. Just take action on some RC issue before you write next message to this flamewar :). If everybody does that way, having such a flamewar will be the most effective BSP in Debian's history :). To be honest with myself, before writing this mail I've looked through the list of current RC bugs, found one that was last posted long ago, and submitted some information there that is probably enough to resolve the issue. That was bug #274873. > 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? My feeling is that many more maintainers don't take care much about their packages, and testing/sid issue has nothing with this. We have currently at least hundred of thousands of bugs open. Say, half of those are wishlists and probably shouldn't count, but the rest 50,000 are issues that require action! Many are open for months and years. Nikita -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBfA3bv3x5OskTLdsRAu/wAJwOkabMCf7xca0sB5RFEaxPCKverQCgvM9i HWrXyk6RkAFJhhxenNi3pLk= =R+6W -----END PGP SIGNATURE-----
