Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> writes: > >> The second problem seems to be generic. The reason I looked at >> packages in testing was that they are the packages that are going to >> be released, and if I look at what's in unstable, it seems that I >> might miss what's going to be in etch (e.g., e2fsprogs seems to be >> frozen, and the version in unstable now doesn't seem to be going into >> etch). >> >> Should I look at packages in unstable, and only if the package is >> frozen, look at the one in testing, instead? > > You should check the packages in testing.
This is what I'm doing now. > Then check the packages in unstable. I'm doing this step manually now. > Note what packages fixed the problem in unstable, file an RC bug for > the testing version and close it for the unstable version. That then > reflects the reality and will keep track of the problem. Hm, I know how to submit a bug for the version in testing (this is what I've done), but I don't know how to close it for the unstable version. How do I do that? > Note what packages started to be buggy in sid. Hopefully none. Exactly -- I intend to mirror and check unstable for regressions in this area. I submitted a lintian check for this, if something like it can be installed, it would also help avoid this problem in the future. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
