Re: criteria for acceptable languages for central QA tools in Debian (was: Re: coordination between lintian/piuparts/adequate)

"Serafeim (Serafi) Zanikolas" <[email protected]> Fri, 27 Dec 2024 22:49:12 +0100

Newsgroups	gmane.linux.debian.devel.quality-assurance,gmane.linux.debian.devel.general
Message-ID	<[email protected]>

hi Jonathan,

On Thu Dec 12, 2024 at 3:36 PM CET, Jonathan Dowland wrote:
> On Wed Dec 11, 2024 at 10:57 PM GMT, Serafeim (Serafi) Zanikolas wrote:
> > I'd like to discuss this with a focus on general principles, and only 
> > discuss specifics (adequate, golang) to the extent that it helps 
> > reason about general principles.
>
> That's going to be pretty hard, because the scenario you present is 
> still pretty specific.
>
> > so we have a qa testing package that was written 11y ago in perl, and 
> > has been orphaned for almost all of that time (10y!). it's not 
> > critical but it does serve a purpose, and it's therefore nonideal that 
> > it's been orphaned for so long.
>
> Certainly non-ideal. "Orphaned" does not give the full picture about the 
> state of the package, however: It could describe a package with critical 
> bugs that aren't getting fixed, or nobody doing any QA or NMU uploads of 
> it ever. Neither looks true for adequate.
>
> > someone takes it over and rewrites it in a language that runs in all 
> > supported arches, and likely in many ports too as long as they keep up 
> > with a relatively recent version of the language (in this case, a 
> > version released 1.5y ago).
>
> "likely in many ports too" is dancing around the fact that it *doesn't* 
> run on at least one port, hence Holger's complaint.

which one? https://buildd.debian.org/status/package.php?p=golang-defaults
suggests that go is available in all ports and the issue is that many are on a
several years' old version. I chose to use a couple of stdlib packages that are
"only" 1.5y old. the use of those packages could be trivially eliminated but I'm
rather skeptical that having adequate run on those ports is the most pressing
matter for those ports (as I wrote earlier: most adequate checks are arch-indep
and those that are not, are unlikely to manifest only in ports). patches welcome
to eliminate the use of those packages by anyone feeling otherwise

> > on a meta level: I find it incredible that this conversation needs to 
> > be had at all, given the increasing median age of Debian contributors, 
> > and the limited popularity of perl among younger people
>
> The "Perl Problem" is a wider issue we should explore in much more 
> depth. I'm personally a little surprised if it's true that younger 
> people are unprepared to take a stab at hacking Perl. But since that's 
> the case, we have deeply embedded, critical stuff written in Perl 
> everywhere. "adequate" is but the tip of the iceberg.

"unprepared" is the wrong diagnosis imho. I fully agree with the responses of
Richard Lewis (perl's okay, but old perl contributors gradually fade away
without replenishment), Matthias Urlichs (life's too short to put up with weak
type checking) and Marc Haber ("Since Debian doesn't pay, it needs to have
comfortable or cool tools").

thanks,
serafi

signature.asc (application/pgp-signature, 833 B)