On Thu, 4 Apr 2024 at 11:22, Arnie T via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi,
> There's no such thing as a "distro decision" on this one, as was
> explained in the thread already.
I'm sure the 'explanation' is all clear to you and the other Developers.
I'm also sure that it's not all that clear to non-Developers.
If the explanation was clear and obvious to me, here or anywhere ales, I wouldn't be asking the question.
So, sorry, I guess.
I guess I don't understand how a Distro decision is different from a Distro IN-decision.
Linux distributions are generally 'collective anarchies' where most packages are up to the individual packagers to support how they want things. 'Collectively' they will elect some group who will work out various high level things like 'where should the files go?' 'how should the files be packaged', 'what should we call ourselves', etc. These decisions may override what the upstream (aka the people who write the compiler, kernel, compression libraries, graphics, etc) but again it is usually a compromise.
How a decision to drop xz for some other compression library for software would be a fairly slow process. First a person who is willing to do the work would come up with a proposal on why it should be done and how it could be done. They would be expected to also test to see how much trouble this would be (aka find all the packages which use xz and could be changed to another library, which ones couldn't and what the effects would be.) Once that is done, they would make a general proposal to be reviewed by whatever technical committee a distribution has (Fedora has one whose acronym is FESCO, Debian has another or multiple others, etc). This would be reviewed and if accepted it would go as a future release work with a staged plan where some packages are moved in X release, some in X+1, and some final plan for X+2 (or backed out completely for some reason before then). There would be some amount of software which would rely on xz no matter what because either the upstream has no interest in changing or it is meant to use xz period.
Usually this would take a key person to drive it who understands the problem and a team of people who would be interested in actually doing the work. Without that the change will move slowly over many releases like the licensing change to SPDR.
This is how a change would happen if it were decided to be done. At the moment the distributions are first trying to figure out a couple of more important things:
0. What happened?
1. What else might have been affected
2. What projects that are also in similar straights
3. What can be done to help these projects (is it inside our sphere of control or influence).
4. What is a list of things that need to change.
...
N. Is moving off of these projects needed or possible?
Currently most groups are between 0 and 1. There are a lot of things which need to be looked at before moving off can be looked at as a goal to make sure we aren't making things worse.
I hope the above helps
For example from what I can read you were in contact with this Jia Tan 'person' during this story.
I hope that a Distro decision would support whatever it takes to give you the tools, time and support to make sure that this sort of thing doesn't sneak past you or anyone.
If there's no way to make that kind of decision then it seems to me Developers could use better support.
This all seems like a very big deal. Which is why I guess I am reading about it on The Economist. And why I'm hoping that the Distro has some options to take some actions.
Cheers!
Arnie
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
