Sam James <[email protected]> writes: > Arthur Zamarin <[email protected]> writes: > >> Signed-off-by: Arthur Zamarin <[email protected]> >> --- >> ...25-08-23-stable-hppa-keywords-removed.en.txt | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> create mode 100644 >> 2025-08-23-stable-hppa-keywords-removed/2025-08-23-stable-hppa-keywords-removed.en.txt > > LGTM. I'm of course a little sad over it, but it's too expensive for me > to run my own machine 24/7, and the backlog of trivial stablereqs means > then I don't have much time/energy to work on "real" hppa bugs. > > So, if anything, this (and the sparc change) may well mean the arch ends > up in a better state.
I was going to write an explanation for somebody else and figured I'd write it here just for completeness: the reason we're doing this (and for hppa) is that stabilisation requires a high amount of effort. The following is so I can link to it when people ask.. Many packages get frequent releases. We recommend 30 days before a new version is considered for stabilisation (exceptions apply for special packages where they need updates to keep working with an external service, security fixes, minor bug fix releases for regressions, etc). If something starts to fail tests on an arch, this blocks the process and someone has to investigate. This of course is invaluable in finding regressions, but it requires a lot of time to sit and check what an issue was. On slower machines, they're often timeouts or some other transient failure. But you can't know that until you sit down and check it. And there's a huge number of other such issues which affect arches/platforms where stabilisation actually benefits people. sparc and hppa (in particular) never had huge userbases but the question is not "is stable a good thing", but rather "is it actually helping people on this arch, and is it worth it"? Combined with the lack of hardware right now (our hppa machine seems to have died and my home one is too expensive to run 24/7; our sparc one uses too much power and the power management patches from Oracle were never ported to newer Linux versions or upstreamed), all we're really doing is making people frustrated with our portability because the delays in sparc or hppa completing stabilisation hold up the whole bug, cleanups, and also prevent automation from flagging new versions for stabilisation for other arches. Destabilisation doesn't mean we're going to remove an arch, just that the trade-off for being able to compile & run tests for a package very often (and having someone be able to check on failures) has moved for these arches. sam > [...]
