Re: Release sprint results - team changes, auto-rm and arch status
On 2014-01-05 08:16, Steve Langasek wrote:
> On Tue, Dec 31, 2013 at 10:34:49AM +0100, Niels Thykier wrote:
>> [...]
>
>> On a related note, I suspect a good part of this problem would go away
>> if we had an automated tool to deal with the case where a (sid-only)
>> FTBFS is ignored. It happens sometimes that the maintainer does nothing
>> (or, maybe, does not realise the package FTBFS on arch X) and neither
>> the porters nor the buildd admins filed a bug for it.
>> Then it is not until the package gets in way of a transition (or some
>> other RC bug fix), that the package gets its RC bug. I have seen a
>> package stuck in sid for at least 90 days and still no RC bug - the
>> "only" thing wrong was an "Out of date binaries" on some architecture
>> (don't remember which package nor which architecture).
>
> Historically, it was considered the porters' responsibilities to deal with
> these packages that are failing to build in unstable. Indeed, this was even
> expressed in the release criteria at one time: a port is not releasable
> unless it's x% up-to-date, because not being up-to-date for any reason
> (buildds offline, porters not signing builds timely, toolchain or individual
> packages regressing on one particular architecture) causes problems for
> testing migration.
>
> Maybe it's time to draw a new line on
> https://buildd.debian.org/stats/graph2-week-big.png, corresponding to what's
> actually needed for a port to be releasable?
>
I believe that requirement is still present (in a slightly different
form and vastly more implicit[1]), the problem is Debian has grown. The
"back of the envelope" number for that graph is 98%, so hurd is the only
one failing this requirement at the moment.
Lets take an example and put 98% into concrete numbers for amd64.
Currently, the buildd page for amd64[2] lists the following numbers for
the following states:
* installed: 10862
* failed: 4
* build-attempted: 44
* bd-uninstallable: 6
* auto-not-for-us: 109
We simplify a bit and say 50 of these are "out of date" (i.e. latest
version has not been built yet) and 10850 are up to date. That means
amd64 currently have 50 out of 10900 possible packages out of date,
which translates to about 0.06% out of date packages blocking testing
migration. In fact, amd64 can have up to about 218 packages FTBFS
without amd64 crossing that line.
This number is similar for many architectures. While a package often
fails on more than one architecture at the time, it rarely fails on all
architectures (except the maintainer upload)[3]. So the architectures
can easily cover 400+ FTBFS without any single one of them passing their
98% line[4]. But that is still 400+ packages stuck in sid potentially
blocking transitions or RC bug fixes from reaching testing. Or up to
400 unfiled RC bugs...
Example aside, what we can see is that kfreebsd + sparc (and ia64) is
currently the lowest, but still got 98.5%. If we push it to 99%, we
would be killing all architectures except i386, amd64 and armhf.
Actually, I could be tempted to push the requirement to 99%.
Architectures still have over half a year and the "only" have to improve
at most 0.6%. Using amd64 as baseline, that would translate to 60
packages or about 10 packages a month (over 6 months).
~Niels
[1] https://release.debian.org/jessie/arch_policy.html
"""
Archive coverage: The architecture needs to have successfully compiled
the *current version* of the overwhelming part of the archive, excluding
architecture-specific packages.
/Our back-of-the-envelope number is 98% of the archive. [...]/
"""
Actually, the requirement is a mix of the one list and having built 98%
of all packages in the archive - except we excuse ourselves by saying
that we do not have a good accurate way to find the "100%" mark for a
given architecture (due to arch specific packages etc.). But if the up
to dates falls below 98%, then the architecture certainly do not have
98% of the "current version".
[2] https://buildd.debian.org/status/architecture.php?a=amd64&suite=sid
[3] Well, more often than I would like.
[4] In fact, I take the pessimism to an unrealistic/theoretical level
and let it cover over 1500 packages without any architecture crossing
the 98%-line.
Reply to: