Hi, On 27-09-2025 18:02, Sebastian Ramacher wrote:
That's effectively the same as what I propose to do with the hints. I mean, contrary to autopkgtest that can regress in a source package in testing without a change to said source package, reproducibility doesn't (or maybe to be totally correct I should say shouldn't) change. So, I can statically create these hints once and that should cover your concern.No, it does not. One approach requires a human to keep track of the list, the other approach is automated by tooling.
Sure, it's work to create the list, but I'd want to be monitoring anyways. And it's work to keep track of things that are fixed, but if I file the bugs, I'll also get the notifications. I need to have the list to file the bugs anyways; converting them to hints is then trivial. There's precedent, I'm doing similar things for the autopkgtest. Yes, it's work but somehow I like it. It's how I joined the Release Team.
I'd expect r.d.n to be able to produce the same information for testing
They already do.
which then can be checked if a candiated regressed or not.
I think I tried to say it before, but these things can only regress in unstable. Your proposal would automate checking what gets fixed, sure. But the code that I created already works as I designed it. It would be *more* work now to change my proposed code to do what you ask. I judge it more in line with the future to not spend the time on changing my britney2 code proposal. We can always change it later if I misjudged the amount of work.
Paul
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature