Re: Candidates for removal from testing (2013-06-30)
On 2013-07-01 08:21, Lucas Nussbaum wrote:
> Hi,
>
> Thanks a lot for this work.
>
> On 30/06/13 at 23:32 +0200, Niels Thykier wrote:
>> We are considering removing the following packages from testing as
>> they have unfixed RC bugs filed against them. The packages can be
>> found in the attached dd-list.
>>
>> The packages have been selected based on the following criteria:
>> - The package had at least one RC bug without activity for the past
>> 14 days.
>> - If a bug is assigned to multiple packages, both packages will
>> be affected[1].
>> - The RC bug affects both unstable and testing.
>> - The affected package does not have any reverse dependencies in
>> testing.
>>
>> - One of their RC bugs had "FTBFS" in their title. (*)
>> - The source package had ai popcon inst value of 500 or less. (*)
>>
>> (*) These extra filter rules was applied to keep the list "down". The
>> original list was 246.
>>
>> If the relevant RC bugs in the affected packages (those listed in
>> "FTBFS-w-popcon-lt-500.txt") are not dealt with before the 8th of
>> July, the packages will be removed from testing. Note that "dealt
>> with" may also include downgrading a severity-inflated bug or fixing
>> affected versions in the BTS.
>>
>> For reference, the original list is also included.
>
> Those criterias mix:
> - criterias that apply to the RC bugs (no activity for > 14 days,
> affects testing+unstable, title contains "FTBFS")
> - criterias that apply to the source package (no rev-depends,
> popcon<500)
>
Yes, all of them has to apply for the bug/source to appear in the
"removal list".
> Some time ago, I experimented[1,2,3] with coming up with a list of
> criterias for "important packages" (which I just renamed to "key
> packages" to avoid the confusion with priority:important).
> Key packages are packages that must be part of our stable releases
> (= that must be in good shape to allow a Debian release).
>
> Currently, the following criterias are used:
> | Key packages are:
> | - packages whose popcon is higher than 5% of the max popcon (that's
> | >7570 insts currently)
In practise, we have err'ed on the side of keeping packages already at
popcon >= 1000 (possibly even lower). When we applied the popcon <= 500
filter on the FTBFS bugs, it "only" took out about 25-30 bugs (leaving
us on 102 RC bugs).
> | OR
> | - packages of priority >= standard
> | OR
> | - packages of section debian-installer
> | OR
> | - debian-installer, debian-cd, piuparts
> | OR
> | - build-dependencies of key packages [binary dependencies are covered
> | by the popcon criteria]
>
Those are definitely keepers.
> [1] https://lists.debian.org/debian-devel/2013/05/msg00496.html
> [2] http://udd.debian.org/cgi-bin/key_packages.cgi
> [3] http://anonscm.debian.org/gitweb/?p=collab-qa/udd.git;a=blob;f=web/cgi-bin/key_packages.cgi
>
> I think that having such criterias, and such a list of packages, would
> be useful to better direct the work of RC bug-fixing. For example, there
> are currently 1517 RC bugs affecting sid, but only 287 RC bugs affecting
> sid's key packages. Of course, fixing all those 1517 RC bugs would be very
> nice, but we might want to focus first on the 287 bugs, as those are the
> ones really preventing Debian from being releasable.
> Typically, the "key package" criteria could be used as a filter on
> http://udd.debian.org/bugs.cgi .
>
> Could you please comment on the criterias for key packages? I would like
> an "OK" from the release team before adding this to bugs.cgi, so that it's
> not just "lucas made up those criterias".
>
Well, I could be interested in using your dataset for making my life
easier for finding these candidates (i.e. reduce the amount of manual
filtering I have to do).
It could also do as a reasonable way of producing "draft" removal
list. I have been asked if it was possible to periodically generate a
data set that could be exposed to the PTS. I think your script is
currently in a better shape for that purpose (even it may include
non-leaf packages).
But I cannot comment on whether we (the Release Team) are going to
endorse it beyond that.
> Thanks,
>
> Lucas
>
>
~Niels
Reply to: