Re: An idea about testing
"Nikita V. Youshchenko" <yoush@cs.msu.su> writes:
> Hello.
>
> After reading some recent postings to -release about non-perfectness of
> testing, I've got the following idea.
>
> There are many reasons (other than actual bugs) why particular packages
> don't propagate to testing. Some of those reasons are somewhat
> fundamental (e.g. huge dependency chains). But not all reasone are such.
>
> Currently, the latest sid version of each binary package is the candidate
> to propagate to testing. That means that if a new version is uploaded to
> sid, this delays the propagation for another 10 days. And if dependency
> chains are considered, the actual delays caused by new sid uploads become
> much more than 10 days.
>
> However, why only the last sid version is considered?
> The idea is: let a particular version of package to become a candidate for
> testing, and be such a candidate until it either enteres testing or there
> is a very serious reason to replace the candidate version be a newer one.
>
> Any sid upload is not a "very serious reason". Possible "very serious
> reasons" are:
> - Á fix of a RC bug,
> - sid upload with urgency=high (or perhaps a new field may instead of
> urgency may be introduced),
> - candidate versions of more than N other packages depend on later version
> of this package.
>
> I have not performed a research about what effect this will have on the
> testing, but I guess that this will make it work better. At the other
> hand, it should be not-so-difficult to implement.
>
> What do you think on this?
Currently there can only be exactly one version of a package each in
stable/testing/unstable. Also only one source package each. You would
need to change all that.
Also consider the size increase of keeping all sid uploads. Thats 0.5G
a day increase.
MfG
Goswin
Reply to: