On 12.12.24 19:16, Jonas Smedegaard wrote:
Frankly I am not comfortable having Asterisk enter into Debian, with a team where those to be counted as active has such reluctant interest in gaining experience with the machinery crucial to the work ahead.
One might note that the crucial machinery consists, at first approximation, of our bug tracker, resp. the list of active bugs therein.
Asking the bug tracker for ?src=asterisk, i.e. not filtering for release, results in exactly one open RC bug, which is the one that complains about "commitment to stable updates".
The fact that tracker.d.o complains about issues in bookworm is a minor detail here and I can't fault people for not wanting to delve into yet another Debian subsystem – one with a list of open bugs that's longer than Asterisk's (and with at least one older bug), which moreover is tangential to our actual goal.
That goal is to (a) close #1031046 and (b) get Asterisk into a shape that's long-term maintainable without deep understanding of the mechanics of its packaging (because there *are* no special-sauce mechanics).
IMHO (b) is kindof a requirement for (a).I can justify taking some (paid) time to help fix the problems that prevent Asterisk from being as easily maintainable as any other not-quite-trivial package. I cannot justify committing to watch over something that requires an hour of delving into the mechanics of build systems that pre-date git to even understand what I need to do.
IMHO² fixing a security bug should consist of five steps: * git checkout stable; git pull salsa stable-updates; git fetch upstream * git cherry-pick «upstream_commit_id»* dch && git commit --amend -c HEAD debian/changelog # or something along these lines
* git debpush * … there is no step five. Can we get to that point, for Trixie? -- -- mit freundlichen Grüßen -- -- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
