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

"Serafeim (Serafi) Zanikolas" <[email protected]> Wed, 11 Dec 2024 23:57:14 +0100

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

[forking to -devel]

On Wed Dec 11, 2024 at 11:15 AM CET, Holger Levsen wrote:
> On Tue, Dec 10, 2024 at 09:38:57PM +0100, Serafeim (Serafi) Zanikolas wrote:
> > > On Sat Dec 7, 2024 at 5:15 AM CET, Paul Wise wrote:
> > > Probably adequate is the logical place for this test, but adequate
> > > doesn't build/run on ports architectures since it moved to golang,
> > > so piuparts should probably keep its tests on those arches until
> > > adequate moves to a more portable language or golang gets ported.
> > that's because unsupported ports architectures have not caught up to go 1.21,
> > which was released ~1.5 year ago. I'd claim that that says more about the
> > viability of those ports, than the suitability of go for Debian tooling. if you
> > feel strongly otherwise, I'd be happy to continue this discussion with a wider
> > audience at <[email protected]> rather than reply here
>
> I dont feel strongly about this, but I'd like to point out that I
> disagree. IMO it was wrong to rewrite adequate (as any central QA tool
> for Debian) in a language which is not available *everywhere*.

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.

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.
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).

given the above, this feedback is very surprising to me:
> IMO it was wrong to rewrite adequate (as any central QA tool for Debian) in a
> language which is not available *everywhere*.

first, I find this concern of little practical relevance: most adequate checks
are not arch-specific.

second, I'd not have adopted adequate if I had to maintain it in perl. given
this clarification, would you prefer the status quo (poor ports coverage but
active adequate maintenance) or would you rather still prefer an unmaintained
adequate with 100% ports coverage?

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

thanks,
serafi

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