Re: coordination between lintian/piuparts/adequate

"Serafeim (Serafi) Zanikolas" <[email protected]> Wed, 11 Dec 2024 22:14:17 +0100
Newsgroups	gmane.linux.debian.devel.lint.devel,gmane.linux.debian.devel.quality-assurance
Message-ID	<[email protected]>
hi Holger, thanks for the feedback.

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:
> > > 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 <D4CWM2UJBXDS.339WS39VNMVYO-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 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'll reply separately to this (addressing -devel) because I think that this
subject warrants wider visibility.

> > piuparts relies on humans to file bugs. autopkgtest on the other hand blocks
> > package migration to testing (that is, when one does not run autopkgtst before
> > upload). it's nice that some humans (including yourself) file bugs, but that
> > doesn't seem viable long-term. 
>
> >90% of the piuparts bugs in the last 2 decades have been filed by 3 people,
> this might not seem viable long-term to you, but in practice it has been
> proven to be viable long-term.
>
> also: piuparts failures block migrations without anyone having to file bugs,
> just like autopkgtest. (oh, and for autopkgtests related bugs, there are also
> very few humans filing them.)

is that really the case for piuparts for adequate results? the checked-in code
has "settings.warn_if_inadequate = True" so piuparts doesn't treat them as
errors. if that default is overriden and adequate errors are actually reported
as piuparts errors, thereby blocking migrations to testing, it'd be weird if
what Paul wrote:
> IIRC piuparts.d.o doesn't expose adequate results to tracker.d.o,
is true (as in, migration is blocked without a hint as to why)

in any case, imho the main benefit of running adequate in piuparts is
archive-wide coverage. I'd prefer to see adequate ran directly as an
autodep8-style test (but fully expect that to be a slow and painful process) to
avoid the downsides of piuparts:

- I expect more people to be running pre-upload, autopkgtest than piuparts
- adding new tags in adequate requires also updating piuparts, for the latter to
  use the new functionality (arguably this could be fixed by not hardwiring a
  tag names in piuparts)
- configuring adequate (e.g. to disable certain checks) is much simpler
  with autopkgtest than when one has to wire things via piuparts

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