On Fri, 03 Oct 2025 11:17:15 +0200 Giovanni Biscuolo <[email protected]> wrote:
> 1. «make a more prominent checklist» as proposed by Ludo' [3] _and_ > make sure that all committers read and understand it (at least when > they apply as commiter candidates but should be better once in 6 > months): a sort of gentle committer agreement :-) There is also some room for interpretation of the manual and no real guidelines to interpret things. On one hand you're not supposed to break anything as per "22.10 Submitting Patches" but apparently there are also times where it's OK to break things, like when upgrading compilers, for instance to do a release that is badly needed. If we come up with some clarification we don't necessarily need to be very precise, it could just steer people in the right direction. Another possibility would be to somehow abstract that away with automatic tests, but could also bring a discussion on what kind of tests to accept. I've not started submitting tests for my use cases yet so I've no idea how this works in practice so far. In the case of libxml2 I didn't follow the issue closely but it's a library that is widely used either directly or indirectly (it shows up in ldd), so an idea here would be to define what should really not be broken with the number of reverse dependencies, like it is done for rebuilds. And we already have that: > Changes which affect more than 300 dependent packages (*note > Invoking guix refresh::) should first be pushed to a topic branch > other than ‘master’; the set of changes should be consistent—e.g., > “GNOME update”, “NumPy update”, etc. This allows for testing: the branch will > automatically show up at ‘https://qa.guix.gnu.org/branch/BRANCH’, with > an indication of its build status on various platforms. And: > $ guix refresh -l libxml2 > Building the following 7551 packages would ensure 24581 dependent > packages are rebuilt: [...] But this case is also special because security is involved (why below), so we can also define a separate case for security (I really think we should). So the question here would be more how to handle security updates on critical libraries. OpenSSL would also come in mind here. I previously tried to send patches for that but I wasn't comfortable enough with grafting, so I sent them against OpenSSL as-is, hoping that other would pickup that work. And here it's probably better to have really clear way to do things because people typically stress out when security is involved, so mistakes are way easier to do. For instance what if one day there is active exploitation of OpenSSL or even OpenSSH in the wild and that we need to patch in a hurry? Or that the Linux kernel provides remote code execution through simple TCP or UDP packets? People would have a huge stress and urge to fix. And if things break the stress increase even more, which can lead to even more breakage and also no ability to fix the security issue since everything is broken. So is there some process that could work where Q/A and reviews are done and things are pushed relatively fast, with minimal risk of breakage? Maybe we need a security team to help? Or maybe, when issue happen, we would need a way to recruit people fast to help fix a serious security issue, and get priority on the reviews and QA? And here I think that it's important to treat security as a special case because of the stress involved and the urge to fix as fast as possible. And if we do that it would also bring a bit more clarity to what not to break. And if this is done right we would also need to find ways to have less and less to do when security issue come up, because if it's the same people that are doing the work again and again there is a huge potential for burnout, so it would necessarily require to explore automation and sharing of work for handling security issues. Denis.
pgpULtwXrnb0F.pgp
Description: OpenPGP digital signature
