On Mon, Jan 01, 2001 at 02:04:51PM -0600, Manoj Srivastava wrote:
> >>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
> Anthony> Well, even Joey Hess has slipped up in his religious debconf
> Anthony> uploads and had four or five delays longer than a fortnight
> Anthony> between updates. Basically, though, at some point the
> Anthony> maintainer has to decide "I'm happy with this" and leave
> Anthony> well enough alone for a little while.
> Umm. This is an artifact of the implementation, and does not
> seem to have a rational design principle behind it, unless I am being
> very dense.
The idea is that for a package to get into testing it should:
* be synchronised across architectures
* have all its dependencies met, and not break the dependencies
of other packages
* not have any RC bugs
The first two of those points can be automatically checked, and are. The
latter point, though, requires people to actually try the package,
and report any problems.
For the latter to be of any value, there are two further requirements. One
is that you give people a little time, both to install the package and to
leave it around long enough that people have a chance to see if it breaks
in normal use, or similar.
Given the way Debian generally works: most people running apt-get
dist-upgrade every day, then the only package that's going to get any
testing at all in normal use is the very latest one, not one from a few
days ago that's already been obsoleted.
There are a host of technical problems as well: you can't tell whether
bugs apply to the new or the old version, there's no way to get at the
appropriate old versions, the code was written expecting there to be
exactly one candidate for each source package and does break if that's
violated, the number of possible combinations of packages to try is
fairly unreasonable already, trying old versions as well is non-trivial,
and so on.
The times (14 days for low, and 7 days for medium) were taken from
the time it usually seems to take the autobuilders to get a package
sync'ed across multiple architectures, which is usually around a week
or a little longer. If you're doing the upload every other day thing,
you'll tend to fail the first check in any case.
> >> 4. How can I know precisely why my package has not been included in
> >> testing. I know update_excuse.html on ajt website ... but that's not
> >> enough. I want to know for example that my libdbd-pg-perl package is
> >> waiting on perl-5.6 (or on postgresql) to be integrated ...
> Anthony> You have to look at your dependency list, and investigate it
> Anthony> yourself. :(
> Where does the pice of code reside that determines whether or
> not a package is going to be moved into testing? Can one extract that
> code into a purely reporting agent?
auric:~ajt/testing/testing/dpkg.c:check_installable() and
~ajt/testing/testing.xs, and ~ajt/testing/update_out.pl. And you can
try. :-/
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
