Hi Michał, I do agree with the gist of what you're saying, and in absence of a better solution I'm in support.
I also make a disclaimer: I only use amd64 so none of this really affects me, so at the end of the day - I don't really care. We have tinderboxes already running that does all kinds of testing for amd64 and specifically, both musl and glibc as far as I'm aware. This could be trivially extended to x86 by way of chroot I believe. Given emulators I believe it's also possible to extend this to other arches at somewhat crazy CPU overhead costs, and I'm not convinced of the reliability of these emulators vs real hardware but for the purposes of this discussion it may be a moot point (if it works on the emulator it's more likely to work on real hardware than the other way around). Given the work on nattka, is it possible that nattka could be extended, in collaboration with he tinder hosts to submit a specific package for compile testing? Specifically for security (and possibly stablereq) bugs I'm thinking have the tinderboxes do the compile tests, as requested by nattka, and then once amd64 and possibly x86 has confirmed, give the security team the option to force stable on the other arches? This may seem to be more controversial than dropping stable for those arches, however, consider that ~arch just gets marked anyway, so frankly, we're no worse off than with dropping stable for these arches. The point of controversy is that we're taking out a testing point for packages, and by implication, control as well as responsibility away from the arch teams. I'm also wondering about the overall stabilisation process. To be frank: A LOT of work is being handed over to the arch teams. I'm not against this, but could we possibly come up with a better way? Specifically, if anyone can request a stable request for an arch, and the package maintainer can OK that within certain rules and constraints (system enforced, with arch teams allowed to violate that, so if a package manager can motivate why then arch can overrule). So in essence: 1. Anyone can request stable for an arch on a package. 2. Package maintainer does first ACK (or automatic after a time delay and additional parties has requested?) 3. Tinderbox for compile tests (At least -* and * on the package itself, ideally with "-* single" as well, and any other USE flags as required by single ... this will burn a lot of CPU, which is arguably better than developer time). 4. If there are tests, run these too, and if they all pass, proceed to stable. 5. If there are not tests ... ? Anyway, just some thoughts, hoping to spark some ideas. At the end of the day I agree with Michał (as I read his message) - differentiation between stable supported and security supported doesn't make sense. Kind Regards, Jaco On 2021/10/21 10:05, Michał Górny wrote: > Hello, > > Splitting from the discussion in [1] (moving more arhitectures to > ~arch), I'd like to propose that we remove the "security supported" > architecture list from [2] and instead level security support with > the general architecture support in Gentoo, e.g. by having all > architectures with stable profiles be "security supported". > > Rationale: > > 1. The architecture list seems to date way back and doesn't seem to have > been maintained properly. According to CVS history, the last time a new > architecture was marked "supported" was in 2005; since then, > architectures were only removed. After the migration to new website, > the points of contact for architectures aren't even listed anymore. > The presence of 'ppc' on the list is doubtful at best. At the same > time, 'arm64' is not supported. > > 2. Keeping a separate list can cause confusion, if not make users of > architectures such as arm64 feel belittled. I don't really see why > the Security team should be overriding the overall Gentoo architecture > support status. > > 3. Per the policy, Security team "will not wait for a stable fix on > these arches before issuing the GLSA and closing the bug". The former > I don't have a problem with but how could you close the bug before > cleaning up old versions, and how would you clean up the old versions > when the new ones aren't stable yet everywhere? > > 4. In the end, Security team isn't really respecting this policy. > In the end, this leads to absurdities like GLSA being released before > a package is stable on amd64, and confusing the users [4]. > > While I agree we could probably establish some criteria when GLSAs > should be released, the current policy is incorrect and obsolete. In my > opinion removing the list is the first step towards cleaning stuff up. > > > [1] > https://archives.gentoo.org/gentoo-dev/message/fd18905401a1aec78aa6af7238f5ca1c > [2] > https://www.gentoo.org/support/security/vulnerability-treatment-policy.html > [3] > https://gitweb.gentoo.org/archive/proj/gentoo.git/log/xml/htdocs/proj/en/security/index.xml > [4] https://bugs.gentoo.org/789240#c2 >
