Re: trends.debian.net updated
On Tue, Apr 14, 2020 at 05:36:37PM +0100, Ben Hutchings wrote:
> On Tue, 2020-04-14 at 13:12 +0200, Wouter Verhelst wrote:
> > Perhaps, but it is *also* documented that an upload just to bump the
> > Standards-Version is severely frowned upon. If there is no other reason
> > to upload in 7 years, then the Standards-Version will not be updated,
> > and that is perfectly fine.
And for this reason using Standards-Version to measure outdateness of a
package won't work. Also, if it became RC, the obvious "fix" would be a
NMU to bump it, without doing unrelated fixes to the package (as forbidden
by NMU rules).
Thus, I argue that only an unrestricted upload (maintainer, team or QA)
should reset the clock.
> If a package hasn't been uploaded for 7 years, then:
>
> * At least some of its binary packages were probably built by the
> uploader, not on a buildd
> * If it's written in C or C++, it hasn't been built with all the
> current hardening options that should be used
> * Its binary packages probably aren't repoducible
These are just three examples of _current_ topics. Those mature packages
probably still don't have build-arch/indep, or perhaps config.guess or so
on, problems the rest of Debian solved a decade ago.
Upstream code can be considered done, packaging is an on-going process.
> * It may not build correctly with the current build tools (failure to
> build at all would usually be caught and reported, though)
>From time to time we have "cleaning events" such as removal of compat < 5.
That was great for a drive-by review of old packages. Alas, we have a bunch
of well-meaning contributors mass-fixing FTBFS bugs via NMUs. That's good
for preserving packages for use by our users, but not so good for their
quality.
Thus, forcing a person to visit a package every 5/7/10 years would solve
this. If the maintainer is still there, {,s}he knows best whether the
package should be kept, orphaned or removed. If the maintainer is MIA or
doesn't have the slightest bit of tuits to actually maintain the package,
the package can't be said to be maintained at all. In such a case, someone
from the QA team[1] has the opportunity to triage the package.
A package being orphaned means "fixes welcome". A package falsely claimed
to be maintained is "fixes are blackholed".
> I think we should be rebuilding everything at least once per release
> cycle, so we don't have a nasty surprise when these "mature" packages
> need bug fixes.
There's enough automated testing to spot FTBFS, thus rebuilding would only
recompile against updated toolchain. That's a good idea, but I say we need
a human look once in a longer while.
Meow!
[1]. Everyone is a member of QA.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀
Reply to: