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

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


Reply to: