DebNet (GSoC 2026): early feedback on flagging at-risk packages
Fabio Ruhland <[email protected]> Sat, 13 Jun 2026 09:39:44 +0000
| Newsgroups | gmane.linux.debian.devel.quality-assurance |
|---|---|
| Message-ID | <[email protected]> |
--_000_05e25e2edcbd41e1b0e6e5daae57a482heilbronndhbwde_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi all,
I'm Fabio Ruhland, a Google Summer of Code 2026 contributor working on DebN=
et, mentored by Arian Ott and Christian Kastner.
DebNet uses UDD to model the archive as a dependency graph and a maintainer=
=96package graph, and computes practical metrics (bus factor [1], dependenc=
y impact, and a fragility score [2]) to surface packages that are single po=
ints of failure. The aim is to complement WNPP, the MIA team, and qa.debian=
.org<http://qa.debian.org/> by flagging packages that are becoming undermai=
ntained. Usually the precursor to orphaning, and far more common under main=
tainer overload, before they actually become orphaned.
It's early, and since I want this to be genuinely useful, I'd value input f=
rom people who maintain packages day to day. A few specific questions:
* What would make a fragility signal actually actionable for you, rathe=
r than just noise?
* For bus factor, does counting distinct uploaders over a recent window=
(with team-maintained packages flagged separately) match how you'd think a=
bout it?
* Any existing tools or prior work I should be building on rather than =
duplicating?
More broadly, I'd welcome the perspective of people who have been doing thi=
s far longer than I have: failure modes you've seen where a package quietly=
became a single point of failure, quirks in the UDD data worth watching ou=
t for, or angles on archive resilience I might be missing.
I won't be able to build everything in one GSoC, but I'd like the foundatio=
ns to be shaped by real experience. And I'm happy to collect longer-term id=
eas on the wiki so nothing gets lost.
Project page: https://wiki.debian.org/DebNet
Thanks,
Fabio (Salsa: ruhlando)
[1] Bus factor: how many people would have to step away before a package lo=
ses active maintenance. Here, the distinct humans who actually uploaded it =
within a recent window (team addresses counted separately).
[2] Fragility: low maintenance combined with high dependency impact. A pack=
age few people maintain but many others depend on. For example, a library w=
ith no active uploader for years that hundreds of packages still need to bu=
ild or run: if it breaks, the breakage cascades and nobody is actively watc=
hing it.
--_000_05e25e2edcbd41e1b0e6e5daae57a482heilbronndhbwde_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p>Hi all,</p>
<p><br>
</p>
<p>I'm Fabio Ruhland, a Google Summer of Code 2026 contributor working on D=
ebNet, mentored by Arian Ott and Christian Kastner.</p>
<p><br>
</p>
<p>DebNet uses UDD to model the archive as a dependency graph and a maintai=
ner=96package graph, and computes practical metrics (bus factor [1], depend=
ency impact, and a fragility score [2]) to surface packages that are single=
points of failure. The aim is to
complement WNPP, the MIA team, and <a href=3D"http://qa.debian.org/">=
qa.debian.org</a> by flagging packages that are becoming undermaintain=
ed. Usually the precursor to orphaning, and far more common under maintaine=
r overload, before they actually become orphaned.</p>
<p><br>
</p>
<p>It's early, and since I want this to be genuinely useful, I'd value inpu=
t from people who maintain packages day to day. A few specific questions:&n=
bsp;</p>
<p><br>
</p>
<p></p>
<ul style=3D"margin-bottom: 0px; margin-top: 0px;">
<li><span style=3D"font-size: 12pt;">What would make a fragility signal act=
ually actionable for you, rather than just noise? </span><br>
</li><li><span style=3D"font-size: 12pt;">For bus factor, does counting dis=
tinct uploaders over a recent window (with team-maintained packages flagged=
separately) match how you'd think about it? </span><br>
</li><li><span style=3D"font-size: 12pt;">Any existing tools or prior work =
I should be building on rather than duplicating?</span></li></ul>
<div><br>
</div>
<p></p>
<p>More broadly, I'd welcome the perspective of people who have been doing =
this far longer than I have: failure modes you've seen where a package quie=
tly became a single point of failure, quirks in the UDD data worth watching=
out for, or angles on archive resilience
I might be missing.</p>
<p><br>
</p>
<p>I won't be able to build everything in one GSoC, but I'd like the founda=
tions to be shaped by real experience. And I'm happy to collect longer-term=
ideas on the wiki so nothing gets lost.</p>
<p><br>
</p>
<p>Project page: <a href=3D"https://wiki.debian.org/DebNet">https://wi=
ki.debian.org/DebNet</a></p>
<p><br>
</p>
<p>Thanks, </p>
<p>Fabio (Salsa: ruhlando)</p>
<p><br>
</p>
<p><br>
</p>
<p>[1] Bus factor: how many people would have to step away before a package=
loses active maintenance. Here, the distinct humans who actually uploaded =
it within a recent window (team addresses counted separately).</p>
<p>[2] Fragility: low maintenance combined with high dependency impact. A p=
ackage few people maintain but many others depend on. For example, a librar=
y with no active uploader for years that hundreds of packages still need to=
build or run: if it breaks, the
breakage cascades and nobody is actively watching it.</p>
</div>
</body>
</html>
--_000_05e25e2edcbd41e1b0e6e5daae57a482heilbronndhbwde_--