Hi, On 1/25/26 06:38, Gioele Barabucci wrote:
Now the point of this proposal is to have a _standardized_ and _machine readable_ way to express support for old Debian releases.
To what end?Any automated change that can be performed on a source package should be a tool in devscripts that maintainers can use directly. There is no point in wrapping this tool into logic to check out a project from git, perform the change, commit the result and submit a merge request. It's not even saving the maintainers any work compared to running the tool themselves.
Reviewing these trivial patches takes more time than making the change yourself, and since we're checking in the result of an automated process, we should verify that this result is consistent with what rerunning the process would give us.
For a declarative statement like "we're using debhelper compat level X", the work isn't in changing the declaration, but in verifying that the changed behaviour is still correct. Automating the trivial part just means more "helpful" drive-by contributions of the form "I've changed your debhelper compat level and verified the package still compiles."
Likewise, running "dch --bpo" is not the hard part of backporting. Uploading a backport means that there is at least a modicum of support for this package, so this should at a bare minimum be coordinated with the maintainer anyway.
It makes sense to have automated checks that feed into the maintainer dashboard like "if we upgrade the compat level and rebuild, what changes does this cause in the binary packages?" or "could the build dependencies of this package be fulfilled on stable?", but neither of these needs more information from the package.
Accepting a patch that updates dh's compat level to 13 (or any other patch in general) does not require a maintainer to create a new release right away. Patches/MRs can be accumulated (`bts 1234 tags pending`) and a new release created whenever the maintainer sees fit.
Yes, but that requires drive-by contributors to actually read the existing bug reports, unless we also make these machine readable or mandate the use of salsa -- and again, adding a mechanism to send automated trivial merge requests are more work to handle for a maintainer than giving them the tool in the first place.
Simon
OpenPGP_signature.asc
Description: OpenPGP digital signature
