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.339ws39vnm...@debian.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
Description: PGP signature
