Re: testing to be implemented on ftp-master

[Brian May <bam@debian.org>]

>>>>> "Adrian" == Adrian Bunk <bunk@fs.tum.de> writes:

    Adrian> The important security fix is only in the package in
    Adrian> unstable but not in testing (and the bug report was closed
    Adrian> with the upload to unstable).

I think that this is a good point. Currently if a bug is found in the
stable version, the security fixes from the newest version are back
ported to the stable version. However, in this case, the "fixed"
version will be older then the unstable version.

How will package pools affect this?

    Adrian> The version in testing might be older than the version in
    Adrian> stable (if you e.g. upload a new package for 2.2r3 and the
    Adrian> package from unstable never makes it into testing).

    Adrian> Such things might e.g. be caused if you do a new upload of
    Adrian> your package every week - so one package is never 14 days
    Adrian> in unstable and a new version never makes it into testing.

Some other related points:

1. In the above case, I guess (at least the way I interpreted
Anthony's post) that the latest package you have uploaded that meets
the criteria will go into testing. So, just because you have uploaded
version 2 yesterday, version 1 may still get through.

However, what if version 1 was found to be buggy and unusable? How
would the system know that version 1 was bad, but version 2 was OK?

2. Is the unstable/stable field in changelog still used?

3. Nobody answered my previous question ("when do old files get
deleted?"), so I may have missed the point in 1.


Another unrelated point:

1. IIRC the BTS has tags potato and woody, to allow for tagging bugs
as being specific to a distribution. What affect will package pools
have on this?

eg. If I upload a package to unstable, which fixes bug 10, ideally it
should report to the BTS that it has been closed in unstable. Then
when the fixed package moves to stable (via testing), it should
automatically mark the bug closed in testing and stable respectively.

I have deliberately avoided some issues here, but you should be able
to get the point anyway. Some of these issues depend on what is
decided for the issues above.
-- 
Brian May <bam@debian.org>