On Fri, 1 Aug 2025 16:34:22 +0000 spacecadet <spaceca...@purge.sh> wrote:
> Are you still talking about xlibre? No, nothing in my mail was specific to Xlibre, this is why I changed the subject name. To discuss Xlibre specifically I would need to do more research and try to assess the risk for Guix contributors. Many things can be subjective in that kind of assessments, so I'd prefer looking at the facts myself before joining the discussion on Xlibre specifically (assuming this becomes important and/or that I find the time to do that). Though I found important nevertheless to try to explain what is at stake here more generally, especially because Xlibre isn't the only software that could be affected by this more general problem (I also know another one with potentially similar issues that isn't in Guix and that is famous enough to got an article about it on lwn.net). I also think that it could be easier to separate the discussions on the more general problem and on the specific case of Xlibre. This of course doesn't prevent each discussions to inform each other. For instance if no extremely toxic upstreams exist, all that discussion is pointless. But if there are real issues, and that people are seriously considering packaging software that have such upstream, having some criteria to look at them is something worth discussing. > Most of what you wrote boils down to "what if" the maintainers make > some bad decision or yell at a packager. Not exactly, it's more about finding ways to manage risks for Guix contributors. The Debian documentation that Efraim Flashner pointed to shows that Debian is doing that kind of assessments in some way on a case-by-case basis already and their rationale for doing that makes sense. So I don't think it would be a bad thing to consider doing something like that as well when the health of contributors is at stake. This doesn't mean that we never need to deal with aspects that aren't health related, but these are way easier to deal with as we already have everything we need to do that (we can patch, fork, discuss with upstream, not package because the maintenance is too high, etc). I also can't talk for everybody but for me as long as the contributor experience is okay, I can even contribute to various upstream that have goals that are completely opposed to mine and/or that actively hurt me and other people in other contexts, and I've done that many times with very different upstreams, and these contribution didn't have any negative health effects. These contributions were usually limited to things that a reviewer of a Guix package might ask to contribute upstream (licensing issues, packaging issues) or to things I needed personally or for another project so the cost benefit analysis was good each time. However I would like to avoid being pushed to contribute to projects that try to actively harm some of their contributors when they contribute, and I don't expect that being on my own to try to understand when this is the case will work. And the fact that some people did bring up issues with Xlibre shows that a community response can work here: some people were aware of potential issues and they spoke up. Denis.
pgp1VZCiOgo7W.pgp
Description: OpenPGP digital signature
