Dear Debian Secretary and Debian DevelopersAs per the Debian Constitution[1] (4.2¶3), I'm requesting an extension for the discussion period of 7 days.
Apologies for jumping this on the last minute, I've been off-sick and have been fiercely triaging and catching up with issues the last day or so.
My rationale is that we have some unresolved issues that I think would be prudent to consider before the vote.
For one, some of the options may put some pressure on individuals or teams to implement some features at the wish of the project. We've already had (and even recently) situations like this that caused a lot of friction. So, I believe it would be worth while to discuss how we want to treat this specifically for the next releases. What happens if we decide on an option for Bookworm, and the implementation is nowhere ready by, say, August next year, do we delay the release? Or aim for Bookworm but make it RC for Trixie? Even if we have some consensus about how to address that and the details don't make it in the actual vote, it would still be an improvement.
Other than that, we may have to accept the fact that this GR won't be (and possibly can't be) perfect and that we'll have to apply some touch-ups based on our experiences and further conclusions based on that, and improve upon it again by another GR some time in the future. In the meantime, I think another week of polish will be worth it over the bookworm release cycle, and I'm glad that this topic is at least moving forward and that we get to make some choices together as a project regarding firmware.
Thanks for understanding, -Jonathan [1] https://www.debian.org/devel/constitution On 2022/08/18 21:58, Steve McIntyre wrote:
Hi a11! I'm proposing to change how we handle non-free firmware in Debian. I've written about this a few times already this year [1, 2] and I ran a session on the subject at DebConf [3].TL;DR: The way we deal with (non-free) firmware in Debian isn'tgreat. For a long time we've got away without supporting and including (non-free) firmware on Debian systems. We don't *want* to have to provide (non-free) firmware to our users, and in an ideal world we wouldn't need to. However, it's no longer a sensible path when trying to support lots of common current hardware. Increasingly, modern computers don't function fully without these firmware blobs. Since I started talking abbout this, Ansgar has already added dak support for a new, separate non-free-firmware component - see [4]. This makes part of my original proposal moot! More work is needed yet to make use of this support, but it's started! :-) I believe that there is reasonably wide support for changing what we do with non-free firmware. I see several possible paths forward, but as I've stated previously I don't want to be making the decision alone. I believe that the Debian project as a whole needs to make the decision on which path is the correct one. I'm *not* going to propose full text for all the possible choices here; as eloquently suggested by Russ [5], it's probably better to leave it for other people to come up with the text of options that they feel should also be on the ballot. So, I propose the following: ================================= We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will *normally* be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.). When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. The target system will *also* be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software. We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages. ================================= A reason for defaulting to installing non-free firmware *by default* is accessibility. A blind user running the installer in text-to-speech mode may need audio firmware loaded to be able to drive the installer at all. It's going to be very difficult for them to change this. Other people should be able to drive the system (boot menus, etc.) to *not* install the non-free firmware packages if desired. We will *only* include the non-free-firmware component on our media and on installed systems by default. As a general policy, we still do not want to see other non-free software in use. Users may still enable the existing non-free component if they need it. We also need to do the work to make this happen: * in d-i, live-boot and elsewhere to make information about firmware available. * add support for the non-free-firmware section in more places: ftpsync, debian-cd and more. and I plan to start on some of those soon. [1] https://blog.einval.com/2022/04/19#firmware-what-do-we-do [2] https://lists.debian.org/debian-devel/2022/04/msg00130.html [3] https://debconf22.debconf.org/talks/43-fixing-the-firmware-mess/ [4] https://incoming.debian.org/debian-buildd/dists/buildd-unstable [5] https://lists.debian.org/debian-devel/2022/04/msg00214.html
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature