[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: