Re: coordination between lintian/piuparts/adequate
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 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
criteria for acceptable languages for central QA tools in Debian (was: Re: coordination between lintian/piuparts/adequate)
[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 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 Description: PGP signature
Re: coordination between lintian/piuparts/adequate
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 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*. > 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.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Any business accepting Bitcoin is participating in the human race’s suicide. signature.asc Description: PGP signature
Re: criteria for acceptable languages for central QA tools in Debian (was: Re: coordination between lintian/piuparts/adequate)
Hi, > [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 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. I don't have the full context here, but to me it seems fine to use various programming languages for the tools. The language landscape is not like version control, where one solution (git) is by far more popular than anything else, and using an obscure alternative would be bound to cause friction to everybody else. If acceptable languages is reduced to a list of top-10 or top-5 on basis of general popularity, the specific language here (Go) would be on it. If the list had certain criteria, such as support for (almost) all Debian architectures, Go would still be on the list. I am not young anymore, but I and young enough to not have learnt Perl in the 90s, and if I see a Perl tool in Debian, I tend to not contribute to it. My own preference is Python, but I see a lot of good tools being written in Go and in Debian we have multiple recent new and very capable contributors doing stuff in Go (Thanks Serafi for adquate! Another is Nicolas who wrote lintian-ssg in Go). I am happy to touch occasional Go stuff to help grow the Debian community, or any other language that is reasonably mainstream and has the full toolchain packaged and maintainer team in Debian.
