Re: Changing how we handle non-free firmware
On 2022-08-23 10:39, Simon Josefsson wrote: Therefor we will not include any non-free software in Debian, nor in the main archive or installer/live/cloud or other official images, and will not enable anything from non-free or contrib by default. The initial proposition was also pushing a new non-free-firmware component. Are you also against a new component that could be enabled by users without enabling contrib/non-free?
Re: Changing how we handle non-free firmware
On 2022-08-23 22:22, Bart Martens wrote: Debian would recommend the one with non-free-firmware, for the purposes of enabling users to install on current hardware, but both would be available. Do we need to recommend one above the other? I'd rather use some short explanation per installer to help the user choose. Maybe we should put the wording on the ballot. Some people may want to be plain factual (this one is 100% free, this one has several non-free bits that may be needed on some hardware), some people may want minimize one (non-free firmware needed in some situations), or the other (non-working installer on most modern hardware). For example, I would vote for the last one. Users may not try the second image if the first one fails because they don't know if their problem may be related.
Re: Changing how we handle non-free firmware
On 2022-08-23 18:50, Jonas Smedegaard wrote: I would find it problematic if the official way to install Debian *required* a non-DFSG image. would you also find it problematic if there were *two* official images, a "free one" (as we know it) and a "free one plus firmwares"? As I laid out my reasoning (which you partly snipped), I see no way that could be achieved. Do you? I mean, DSC#1 says that "Debian will remain 100% free" - how is that possible if an official part of Debian is omitted? Or how is it possible for the firmware-containing image to be free? If we consider firmware (not running on the CPU) to not be software.
Re: Changing how we handle non-free firmware
On 2022-08-22 22:13, Theodore Ts'o wrote: So there may be some unintended consequences where new users may associate "100% free software" with "not functional" and "induces pain and frustration", such that it might end up *hurting* the cause of free software. Well, that's the truth when it comes to laptops. I myself consider that Debian is harming free software by making it difficult to deal with this issue, leaving the user with broken hardware that is working correctly on Windows. Even in unstable, we ship out-of-date firmware. For example, rtl_bt/rtl8761bu_fw.bin is outdated and the associated adapter may not work correctly on resume. Just putting the up-to-date version shipped in the latest tarball from the linux-firmware repository is enough to make it work correctly. Back to the vote, another option would be to not consider firmware (not running on the CPU) as software and we keep the 100% free software images with non-free firmware included. This implies this new component should only include firmware (there were discussions to broaden its use in the past). I can briefly rehash the rationale: firmware were previously shipped in a ROM with the hardware and they have been moved to being loaded by the OS instead for various reasons (cost, ease of update), but this does not fundamentally change their nature, except that we have to distribute them. There is no difference in the level of "freeness" we provide to the user, but there is a huge difference in usability.
Re: Changing how we handle non-free firmware
On 2022-08-20 21:49, Bart Martens wrote:
3) Ensure that the filename of the installation media includes
"non-free-firmware" or something similar so that it is clear to
everyone what they are getting into. Debian has had such a long
history of not including non-free bits in the installation image
that people will definitely be surprised if the filename does not
reflect this change.
Actually, people are surprised we are hiding the useful images (with
firmware) somewhere in some subdirectory away currently.
I recognize myself in both. I prefer the installer not including non-free bits,
and the ("unofficial") installer is difficult to find when I need it. Why not
advertise the free and non-free installers side-by-side?
Some people may not understand when they need one or the other. They may
choose the free one and run into trouble and give up.
Re: General Resolution: Liquidate donated assets as soon as possible
On 6/19/22 01:43, Louis-Philippe Véronneau wrote: Text of GR Donations to the Debian project of assets other than the TO's currency of choice should be liquidated as soon as possible. End Text of GR What's a TO?
Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
❦ 18 octobre 2014 12:21 +0200, Luca Falavigna : > Dear fellow Developers, > > I would like to propose the following amendment proposal, > and I hereby call for seconds. > > > > ** Begin Alternative Proposal ** [...] Seconded. -- Format a program to help the reader understand it. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Re-Proposal - preserve freedom of choice of init systems
❦ 16 octobre 2014 16:26 -0400, Paul Tagliamonte : > Here, we will likely do invasive forks of major upstream software > (GNOME) to get around a local requirement; do we expect the GNOME team > to do this? By turning such bugs into RC bugs, the proponents are exactly advocating this position: they put the burden on an under-staffed team. -- Localise input and output in subroutines. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: Debian Maintainers GR Proposal - Use Cases
OoO En cette nuit nuageuse du mercredi 27 juin 2007, vers 01:06, Paul Cager <[EMAIL PROTECTED]> disait: > I'm a fairly active (non-DD) member of the Java Packaging team, and I > also maintain a couple of non-Java packages. Although I'm starting to > become reasonably skilled at Java packaging, I'm far from ready to apply > for NM. For example I don't know all of the details about packaging C > libraries, or Perl etc., and (since I am concentrating on Java > packaging) I do not currently have a desire to learn about these areas > of packaging. It's a "depth-of-knowledge" versus "breadth-of-knowledge" > thing. I may be wrong, but I don't think that DD have to be able to package any language program. Pickup your favorite DD and you will see that either he doesn't know how to package a Java program or he doesn't how to package a Perl program or... -- Avoid temporary variables. - The Elements of Programming Style (Kernighan & Plauger) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
