Re: Candidates question: politics and Debian
On Tue, Mar 19, 2024 at 09:38:26AM +0100, Gerardo Ballabio wrote: > >Another facet of the question is: do you think that Debian should >support and/or take action on "good causes" that aren't part of its >stated mission (and that some people, including some DDs, might >disagree on being "good")? > >For example (by no means an exhaustive list, feel free to add): >- should Debian aim to reduce its carbon footprint and/or optimize >software for that goal? >- should Debian support and/or actively drive initiatives to increase >diversity in Debian Developers, or in the software industry in >general, or in the world at large? >- should Debian take any measures (boycott, suspend or expel >developers, refuse to consider as a host for Debconf...) against >countries that are perceived by some as "behaving bad" -- as examples >related to current events let me just mention Russia and Israel? >- (this is an issue that once hit me personally) should Debian enforce >the use of a particular language with respect to gender issues? Oh, this garbage again. Haven't you learnt yet? The "thing that once hit you personally" was the thread at [1], where you declared that your rights about word choice trump being respectful of the people around you. You're continuing to frame this as "politics". I, and many other people here, have made it abundantly clear that this is not acceptable. You're (still) not a DD, but it seems that you want to continue to try and push this disrespectful world-view in the project. This is elementary stuff - it's point #1 in the Debian Code of Conduct. [2] As you've made it clear that you don't want to abide by the norms of our community, I strongly suggest that you go and find a different place where your views might fit better. [1] https://lists.debian.org/debian-project/2019/12/msg00011.html [2] https://www.debian.org/code_of_conduct -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub) signature.asc Description: PGP signature
Re: General Resolution: non-free firmware: results
On Tue, Oct 04, 2022 at 02:34:33PM +0100, Ian Jackson wrote:
>Debian Project Secretary - Kurt Roeckx writes ("General Resolution: non-free
>firmware: results"):
>> The results of the General Resolution about non-free firmware:
>> Option 5 "Change SC for non-free firmware in installer, one installer"
>>
>> The details of the results are available at:
>> https://www.debian.org/vote/2022/vote_003
>
>6 votes is a very tight margin between "one installer" and "two
>installers".
>
>Observe also that "Recommend installer containing non-free firmware"
>beat "Only one installer" by 12 votes. I hesitate to say this, but it
>seems to me that the hypothetical option "Change SC, recommend
>installer containing non-free firmware" would have won if it had been
>on the ballot.
>
>Certainly given the narrow margin, we should do what we can to make it
>easy for those who want to provide an unofficial fully-free installer
>to do so.
Nod. As I said in my mail and blog at the weekend, my aim is to leave
the options in code and config available to support that.
>I think we might even want to link to it from the official page,
>inverting the way we currently do it.
Maybe, let's see how it goes.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Draft ballot
vjwgHYYisyg/+KsIH2ThddZ2K0GSxEZc95zq/7PvY >jrnbJkhNJ1YAP2shXx1e+VT41ArgwgeoC2vbEI8+wftH4PRoaCXFROasCKBfeUMT >PbnuJCj0Wfsv9aOuJUtrSQ42/FJs9d1f//YsrRndraFqGultJ+S3TgmF33ZzM8OS >950b4VrC2AhQu9dWH8OvcwFMb9rdNRsUYMwbJP7TvzKNBMFmkbWFq2Z4biVRsC7E >gZAULhui1iQaRqSVF2+isGAKXdGscSsWz6nFQ3YtqkgCvjRbUZoliyWoczCLM1GF >lpXvSCOKqPEHImHIXCqPT8gYvkolYQei5IsMahJOK+yLqTNh318ps69kitnn5eFg >W2mvE9mVK0/JjUMZRND2mJy2lXHNo6J0MboXGWVPZXx7wQdeIej3cMTjY5dSHp+m >LB1VHubbFbvVUAxRNJwF2eF+ZGNwz/v3nYIvj6TaEiODaDwtM4XW62jH85Gv9+R7 >RF3bwjwxGdFjgkjUK9DeokMCWOU2SDR1ik7E5JsOnwHgnD+wT2aOsyUQ5GfQzaI7 >5wAD1oeFuDyiIljs6/J0BiyCwsZ155hm32pAG8z/IBikAMGLhyWR1+nWyApbmU18 >L79XSxvj7XZdSv5sU2uXApD3sdUVqH+Yb621TuBs18FMZilXmX0aUYLWGWdKnwqq >cBNzsPloembPDN6JAjMEEAEKAB0WIQTl5SVg3ZHFVt29pdAgZMU2QcJeXQUCYyYo >ywAKCRAgZMU2QcJeXX6eD/0YxNrr6Ws3Ipwrpu7+CuNlidihL157uQ0vv951HNmG >ooEd9I9iOlAtEIlG8JRr7Z4pbE/xcuFddEOTZ6RxATUxOaV/JAG+SVOeB2phyytL >A7KgEd6AVWJvXw3pU/PTWP9jnTt2KfD67ySDb+kA0nXplGZFYpJPOSehM11qt7Jn >UGDr9nKp8Vf+iG6CLnucjTX0Gukqa4miuyK1cvato5IWoOLa0jaUxJKiaVbLw4F7 >hB9+dYEYxsYJ8UcvCZdz0Wkfc4IEPfmz7rDNyYWG8yaJs1Iw1j2sTKbJ/c6UjECV >aVhQhDAEEI0Lc1mjJoeZfey+kF9NUUk79RrwY4sAH7X+ValMM+GwqdHohklcNziL >9IkM3yUf7tWQ6ab1L6o8b6Ux6nSJfD6MIt/SAXU9p+h2c8uD9eVKgzjlwS39yRMK >xsjQgxNh4mJtm96L693nTOFAkFvUNobPOyOLsIJWD9+bzAkz6xa4qchtxBKnwaae >6lCqh2QuvkD7gIbUqqEHWBDQ1tLth/FYLSDehV1IEIAe+yxlonfdAxwnLZ5w5gxI >oD0NDelFcoGlicLd5GLeJAN2x84UN8r4VclYTkzPj4hWasHjbfMjchWX1bBHbdfk >7l8X2I+mws168mRoaKzg9rZFZlmDwLrWdniyHPjB+kLbarCDNowE/wolAPKRIoYk >rrkCDQRjJihWARAApIsgnwY1r2pynk1gLqS6tOLqn9xXchSxceRK6BT1PIgSnO/Z >d0B6N4wavmkUz7AmWNeOBqnLx0KftrocPLItmVsmwiBby86D2eiVALmVMyk7peLR >B0bZIPInKHaVIGZKUGHGhTYk4vyRkgeZO80MQq4AOFgdkligdyjHbI84kYLtSOys >Fj/dLZ/RRony8ciMQxrvHoA5lSRHACGqo4TpqZrOYePceDQBEx7fyPyNqq/jMlXr >I9DZ3aVETxlHDvnepCEaUEf3jsE1IsFYRGMDpqCFqS0ewd/PufGbvqF1EkfF7S+w >LlWBCtujMQj2ibkGs1QQ8rnhcyJxmQ49oHvl5oUvfpDxIckg/9TQb+1ydX9iP93p >iPq6IXa4AuFDEV/InSzYN0qvukVhZqMxzP2uiVll568uCXVKQNa7vMJhc0XcTCa/ >AYRw54aEKcl/p59B2/IYXG5nlN4KXhh8yaPXaIxj9bSXqhgbUtOkYc724Y4hQV4n >nmJ98SBkolquP2uORI3AnzKu+jbfBeoY7yPcM80dFctiPPwR76IH0TZhdxSae5Ar >5yGC3VqfiSUuBlafmBSlbfFSb43l3Ebsf0kQOrlQFLbBZEzxDNgbWzyKicA4AzVH >+hJ23B0GwZpAuaXx95a+A2l+mbqKbxSUI3KWAr7HVosYyj4to5kNmCVnpqUAEQEA >AYkCJQQYAQgADwUCYyYoVgIbDAUJABpeAAAKCRDneu+PCAdhiEWMD/42XRrtk8rw >c+7m0Fwtl8B5Am+6bggFZF5tSKARUo1+8Cv2Lgj0+kgiuM8S0nlZMM4gI0Jk+wyE >ngfqC6ADkuDbybph0oHu1wWEUF9KQe+YIYaS3BwbJBrND0FKxjkHNO+7lZxkC0P8 >pdn3skPw8P4rAE9A9JnwqrJ+4rxUipezn3Vzqv79T5irrnBQSL/c8VGYrZnTaIIL >lmVda+2zdxFDSMgL10LWMvOsL2iFa+/66+coPtY60k56pSw6pqDnH1q+35TZsQQl >V9q/Gn1gCeDBv/Xwsl2fnGv1cRC2kozg4aUyPVnABXJdopzLwgqc5Z+tq5tEh1xZ >LYFe9yZgBvSU77g/kS1GuulTX3k95752T0SY0bJ9bPZWSmBgGQwpisE9aqhoT8iw >HBjStMoPCdaOuEV7yevs4vsJ0MD/pYxEfJoJy5zRGvZyLGeGB7oeKIJytW6kcxD0 >UZqPXOqtFxHfOUmdVkFEdwnBOWNSCM/586iiFRUcw+y6QcjDHKSoBEUBRcUBdtMq >lrHY2wu7QrofWnphttIjp+2URtmusaNDlOJwQupyvdpw1E443RXo4L9kPEakLpCi >30u18kKamT3AuTbmGLu/v6BMTzz2wNjEIznwNIHKrHcDe9NpypO9hXzK/ALPM5RS >8JaOA6+XvtEEaScU43YtKvAgqiKhHcQ3MA== >=HXGh >-END PGP PUBLIC KEY BLOCK- > > > -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... signature.asc Description: PGP signature
Re: new proposal: free and and non-free installers with SC change
On Wed, Sep 14, 2022 at 03:00:26PM +, Holger Levsen wrote: >hi, > >I'm looking seconds for this new proposal below, which is like >proposal E plus *also* offering free installer image. > >Rationale: we should keep producing fully freely distributable >Debian installer images, for those cases were some included non-free >stuff else might limit distribution, eg to Iran or Cuba etc or >by imposing other restrictions...! > > >- >Proposal F > >This ballot option supersedes the Debian Social Contract (a foundation >document) under point 4.1.5 of the constitution and thus requires a 3:1 >majority. > >The Debian Social Contract is replaced with a new version that is identical to >the current version in all respects except that it adds the following sentence >to the end of point 5: > >The Debian official media may include firmware that is otherwise not >part of the Debian system to enable use of Debian with hardware that >requires such firmware. > >The Debian Project also makes the following statement on an issue of the day: > >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. Where non-free firmware is found to be necessary, 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, alongside the current >media sets that do not include non-free firmware packages. > >--- > >(This is exactly "Proposal E" as found on >https://www.debian.org/vote/2022/vote_003 >now, except that in the very last sentence the word "replacing" has >been replaced with "alongside".) Seconded. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183 signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
On Mon, Sep 12, 2022 at 01:13:33PM -0700, Russ Allbery wrote: >Simon Josefsson writes: > >> Wonderful -- it is good that I am able to finally express your view in a >> way that you actually agree with. > >Yes, thank you very much for your thoughtful and productive engagement in >this thread! It's really satisfying to be able to talk about things that >provoke strong feelings and be able to have a productive conversation that >helps both people understand each other. I'd like to express my thanks here to *both* of you! It's been great to have a healthy debate, discussing principles and trying to understand each other. In the modern era of partisanry, this is depresssingly rare and even heart-warming! >> I agree purity leads to cults and problems. My view of this situation >> is that the Debian project is climbing up the stairs of the pragmatists' >> ivory tower to the point where it suffers from the ills of purism: by >> forbidding the free installer, the pragmatist becomes the mirror image >> of a purist that wants to forbid everything that doesn't comply with its >> own ideal. > >> In my mind, the pragmatic approch is to publish both the free and >> non-free installer. > >So, spoiler, while I'm going to vote E first (I have a policy of only >proposing ballot options I would vote first), my guess is that B is going >to win for precisely the reasons you describe. I will certainly vote B >above NOTA. (For full disclosure, my vote is likely E>B>C>A>NOTA>D.) ACK. B may well win, and I'd be happy to accept that - it gives some clear direction! As I've expressed previously, my own personal *preference* is for Option A. but I expected there to be opposition there and I totally understand it. FTAOD, I'm expecting to be happy with whatever the project decides here. >In other words, I think we have a fair bit of common ground. My concern >about having both installers is pragmatic; I don't think it's necessary >and I think it's confusing to users (not to mention additional work that >divides our efforts). But it's certainly not a violation of Debian's >principles. My general policy for votes is that I'll vote my own >principles and let everyone else vote theirs and rely on the voting system >to reach compromises, but the compromise in B (and for that matter C) are >both ones I'm happy with. > >I don't think having only one installer carries the message that you're >seeing in it. I think it's just a more elegant and straightforward way of >providing the user with a choice about whether to use non-free software >and respecting that choice. But I completely understand how you arrived >at the conclusion that you did and I respect your reasoning. In some ways >it's probably more sound than mine. Right! -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Possible draft non-free firmware option with SC change
On Mon, Sep 12, 2022 at 08:18:13PM +0200, Simon Josefsson wrote: >Russ Allbery writes: ... >Okay. But given a situation when someone comes to you with a hardware >component that requires non-free software to work, and asks you to >install Debian on it, would you resolve that by > > 1) install the free Debian system on it and provide them with the > documentation and binaries how to install the non-free software > required after they made their own informed decision > >or > > 2) install the Debian system including the non-free work on it and > provide them with documentation explaining what happened > >? > >I take it yours and Steve's proposals is 2) while mine is 1). Yup, exactly! >And, yes, approach 1) may result in the possibility that you have to say >"sorry, I can't install Debian on your hardware, and here is why". We >say the same when someone comes with an old 8086 processor or a quantum >computer prototype too, too broaden the view a bit. Sure, but right up front those are much more obvious. Most users with a reasonable current-ish machine (FSVO "reasonable" and "current"!) will expect to be able to install and use Debian or some other Linux distro on their machine. If a new user comes along with such a machine and asks for help to install and we say "sorry, can't!" then that's quite an issue. There are lots of distros out there, and it's quite likely they'll just try another that's less picky. If that distro works, the chances are: * We'll never see the user as a Debian user again. * They'll happily share stories of how useless/crap Debian was. The actual details will be lost. Or they may just abandon things and go back to Windows/Mac and assume that Free Software isn't for them. None of these are good for us. -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Possible draft non-free firmware option with SC change
On Mon, Sep 12, 2022 at 05:00:37PM +0200, Simon Josefsson wrote: > >What still puzzles me is that I regarded myself as having worked with a >lot of computer hardware over the years, without experiencing the kind >of situation described here. Yes, some hardware doesn't work with >Debian, but no I would not blame Debian for that nor give up or stop >contributing to Debian because of it, and no, I don't perceive such >hardware to be as overwhelmingly dominant as described. I think the >answer must be that people have different biases to what kind of >hardware they are exposed to. And perhaps a different preference how to >help people who are in an unfortunate situation. You've described it already - you're using a 12yo laptop (X200) with wired network (AFAICS?) and some other non-portable machines. Many common laptops in the last 5-10 years don't come with wired ethernet; it's becoming rarer over time. They ~all need firmware loading to get onto the network with wifi. Many now need firmware for working non-basic video, and audio also needs firmware on some of the very latest models. The world has changed here, and I think your perceptions may be out of date. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
Hi Russ, As ever, I think you've described things very well here. Thanks for this! On Sun, Sep 11, 2022 at 01:22:58PM -0700, Russ Allbery wrote: >Simon Josefsson writes: ... >> I think I'm missing a better problem statement to motivate any changes >> here. The ones I've tried to understand, by watching Steve's >> presentation this year and reading earlier mailing list posts, does not >> convince me: it appears to boil down to a desire to help more people be >> able to install Debian and join the community. That desire is >> understandable, but does not motivate compromising the social contract >> to me. > >This position makes a lot of sense to me. I happen to disagree with it, >but I think I understand why you hold it. I do think you're underplaying >Steve's arguments here, but I get why it's hard to summarize arguments >that you don't agree with. > >The way I would put the argument is that one of the critical goals of >Debian is to be a universal operating system that prioritizes its users >alongside free software, and implicit in that prioritization is that >Debian is intended to be a practical, real-world, usable operating system >for regular computers, not (solely) a research experiment or ideological >statement. And I would say that one of the motives of Steve's proposal >(or, at the least, one of my motives for agreeing with it) is that I think >we, some time ago, reached the point where dynamically loadable firmware >is necessary in normal cases for our users. This is the key point, exactly. I sincerely believe that Simon is *not* being dismissive of these needs here, but it *could* easily be read that way. ... >The reason why I'm saying this so bluntly is that I am concerned that your >wording is approaching the implication that the folks with concerns about >this proposal are principled and the folks supporting this proposal are, >well, less principled in some way, or are compromising their principles. >I don't believe I am compromising my principles; I believe I am upholding >*different* principles than you are, about building something that does >things concretely in the world and values that utility at least equally >with making ideological statements. My disagreement with you *is* a >disagreement of principles, not a matter of you being more willing to >stick with principles than I am. Nod. Believe me, I've agonised over raising this GR (or something like it) for several years before finally getting here. I know there is some soul-searching to be done, balancing the two priorities we identify in the SC: our users and free software. Each developer in the project will have their own position on this, and I'm immensely happy that we've had some healthy and respectful debate here. Thanks to everybody for that. >Also, to be clear, dropping the non-free installer is not on the ballot; >none of the options, including yours as you point out, say that. So I am >not worried that Debian is moving in this direction, and this is an >abstract discussion rather than something I think is likely. But after >reading your message a couple of times, it felt important to me to stress >that I don't feel like those who would prioritize DFSG freeness have a >monopoly on principles here. So... I *do* have concerns about fully advertising a non-free installer image that doesn't meet our stated principles. We've spent years asserting / pretending that non-free is not part of Debian, and we don't really advertise it much. Most people would never really care on their installed systems. However, I feel strongly that the non-free installer *has* to be handled differently. If not, we're choosing to fail on (some of) our principles. This is why I'm here with this GR after all. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
Hi Simon! On Fri, Sep 09, 2022 at 09:16:48AM +0200, Simon Josefsson wrote: >Steve McIntyre writes: > >I read your proposals as a deep frustration with this situation and a >desire to solve the problem faster than waiting for free software >support for relevant hardware to materialize. I don't think this is a >problem that Debian should solve by compromising on the free software >principles. I think this is a problem Debian has been and is (slowly) >solving by remaining what it has been: a free OS. There is much more >hardware that works with free software today than it was 20 years ago. >Many hardware vendors today realize that support for GNU/Linux >distributions like Debian is important for their success. But, being brutally honest, a much larger number of hardware vendors *don't* especially care about Debian and other Linux distros, at least not enough to design special hardware for us with a different firmware setup. As far as many vendors are concerned, the firmware blobs are basically part of the hardware. They're just provided in a cheaper, more flexible way - loading things at runtime. Lots of vendors have made those firmware blobs freely redistributable spefically to enable Linux distros to provide them to users, rather than only embedding them in the Windows or Mac OS drivers. In this world, we have a lot of users with hardware that currently depends on non-free firmware uploads to be functional. Telling users "you need 'better' hardware to run our OS" is self-defeating at best, elitist at worst. ... >I think the difference of opinion is that your proposal is based on the >argument that it is worth compromising on the ideals of free software in >order to allow users to be able to run free software. I disagree with >that opinion. If you disagree with my characterization of your >proposal, let's discuss and see if there is a middle ground somewhere. I think you have it, yes. We're simply disagreeing about what compromises we're prepared to accept. I think that's fair, and fine - I'm explicitly asking for a project-wide opinion on this. This is also why I've seconded several of the competing ballot options. OK? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
On Fri, Sep 09, 2022 at 10:37:03AM -0600, Bdale Garbee wrote: >"Jonathan Carter (highvoltage)" writes: > >> I do think some parts are important to include though, how about: > >I disagree strongly on this. > >We should work REALLY hard to have the SC capture the commitments we're >making to our users, and then stop. Yes! Thanks for pointing this out. I've been re-reading the various proposals around the thread here, and none of them really fit for me. You've hit the nail on the head for me. The point of the SC is describe what *we* aim to do, not what users should do. >Specifically, we should avoid including text that attempts to tell >them what they need to do, such as: > >> We encourage software vendors who make use of non-free packages >> to carefully read the licenses of these packages to determine whether >> they can distribute it on their media or products. > >If you really think we need to say this to downstream consumers / >distributors of our work, I'm sure we can find a way to do that. But >the Social Contract is the wrong place. It is, and must remain, an >articulation of our values and the associated commitments we're making >to our users. The fewer words it must contain to achieve those >objectives, the better. > >> An added goal I'm trying to achieve with this change is to explain some >> practical consequences of redistributing non-free software. > >I applaud and support this goal... but please don't burden our >fundamental statement of core values with such content. I think it *may* make sense to have some extra text *alongside* the SC to explain the ramifications for users, but it doesn't need to be in the main SC text itself. Does that sounds sensible? -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering" signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
[ Apologies for going quiet again - it's been a busy few days, including testing and publishing two sets of point release images. ] On Thu, Sep 08, 2022 at 04:54:06PM -0700, Russ Allbery wrote: >Steve McIntyre writes: > >> That looks good to me - concise and clear. Thanks! > >Steve, what do you think about the suggestion above that we have a ballot >option that only changes the SC and doesn't issue a statement on an issue >of the day, and thus doesn't include the text of your proposal? I'm >worried that may feel like the project isn't providing enough guidance or >a clear enough decision, but I'm not sure if that's true. Quite. I can understand and sympathise with that suggestion, but I'm really hoping for specific direction from the wider project here rather than just a "we allow this" SC update. That latter would leave the decision on firmware-included images solely in my hands, along with the responsibility and (potentially) the blame here. I hope that makes my position clearer? -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone signature.asc Description: PGP signature
Re: "official" image terminology Re: Changing how we handle non-free firmware
Hey Ross! On Thu, Sep 08, 2022 at 08:04:24AM -0700, Ross Vandegrift wrote: >On Thu, Sep 08, 2022 at 11:38:09AM +0200, Simon Josefsson wrote: >> I don't think the word "official" is defined or used in any foundational >> document, nor that its meaning is well agreed on or actually helps the >> discussion. > >I had assumed "official" was in more common usage. It seems like that's >false. Since the cloud team uses that term, here's a bit of detail I >can offer. > >The best doc that I know of is here: > https://wiki.debian.org/Teams/DPL/OfficialImages >This tracks Steve's usage from earlier in the thread. The cloud team >uses it like this too --- we probably got it from him, back when he was >on the team. We also used to have DSA members on the team who seemed >keen on the term. > >So while it doesn't appear in any foundational document, it does have >traction amongst folks that are affected by these issues. Nod. It's been in common use amongst a number of teams over the years. It's been useful particularly when denoting stuff that is *not* official but still distributed by various Debian teams - e.g. test builds or builds including non-free bits. It's been a subject of discussion with the trademark team in the past, too. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Re: Possible draft non-free firmware option with SC change
On Thu, Sep 08, 2022 at 05:22:58PM +0200, Simon Josefsson wrote: >Simon Richter writes: > >> The reason I'm in favor of changing the SC is not that I believe it to >> be a good thing, but that I think we need to stay relevant for running >> on actual hardware, and changing the SC now is the only way to do so >> given that the actual hardware is non-free. > >What has changed making us fear Debian's relevancy, and is compromising >on our ideals the best way to deal with that? > >I recall the same situation with hardware requiring non-free software >since I started with computers and free software back in the mid 1990's. >The challenge will continue be the same as long as there is proprietary >software. The amount of hardware compatible with free software is >enourmously larger today than it was back then. I don't see that Debian >or other free software projects having become less relevant over the >years. In fact, I perceive sticking to these principles (while offering >high quality products and processes) has been instrumental to shift the >proprietary software industry our way. People will continue to talk bad >about free software, and promote proprietary software, but I am hoping >Debian will be a factor against that. You're missing the point. Debian will *still* be producing Free Software. We're talking about enabling people to *use* that Free Software on the computers they already *have*, not some idealised Free Software compatible computers that barely exist today. It's just like the FSF providing support to users wanting to run software on top of proprietary OSes back in the day. If new users cannot sensibly install and use our Free Software on the computers they have, they'll go elsewhere. We won't get the opportunity to educate them about the benefits of Debian and Free Software if they've already discarded our installation media and moved on. We don't get new users, we don't get new developers. None of us *like* this situation, but we have a pragmatic solution. -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
On Thu, Sep 08, 2022 at 10:27:52AM +0100, Phil Morrell wrote: >On Thu, Sep 08, 2022 at 08:00:09AM +0200, Didier 'OdyX' Raboud wrote: >> Le jeudi, 8 septembre 2022, 07.14:09 h CEST Russ Allbery a écrit : >> > Didier 'OdyX' Raboud writes: >> > > While we're at updating the Social Contract's article 5, what about a >> > > more invasive cleanup, to reflect reality ? >> > > >> > Going *way* out on a limb (and to be honest I'm leaning hard against >> > proposing this because I think this level of change would require more >> > than a week's worth of discussion) >> > >> > 5. Works that do not meet our free software standards >> > >> > We acknowledge that some of our users require the use of works that >> > do not conform to the Debian Free Software Guidelines. We have >> > created areas in our archive for these works. These packages have >> > been configured for use with Debian and we provide some >> > infrastructure for them (such as our bug tracking system and mailing >> > lists), but they are not part of the Debian system. We encourage >> > distributors of Debian to read the licenses of the packages in these >> > areas and determine if they can distribute these packages on their >> > media. The Debian official media may include firmware from these >> > areas that is otherwise not part of the Debian system to enable use >> > of Debian with hardware that requires such firmware. >> >> As-is (that is: "changing only SC5 with a 3:1 majority") seems to be one >> very >> simple way to express the change we (some of us) want. The "statement of the >> day" is a nice addition, but can risk being nitpicked-upon. I'd definitely >> second a ballot option that would propose just this. > >In that spirit, some more wording suggestions and justification below. > >5. Works that do not meet our free software standards > >We acknowledge that our users may require the use of works that do >not conform to the Debian Free Software Guidelines. Such packages >are not part of the Debian system, but we provide the enabling >infrastructure as a convenience to our users. This includes the bug >tracking system, installation media, mailing lists and separate >archive areas. That looks good to me - concise and clear. Thanks! -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: Possible draft non-free firmware option with SC change
On Wed, Sep 07, 2022 at 11:38:33AM -0700, Russ Allbery wrote: >Ansgar writes: > >> Seconded. > >> One suggestion: if we modify the Social Contract then we can as well >> include "non-free-firmware" explicitly as well, i.e., replace > >> We have created "contrib" and "non-free" areas in our archive for >> these works. > >> by > >> We have created "contrib", "non-free-firmware" and "non-free" >> areas in our archive for these works. > >I considered doing this, but then I decided against it because I think the >current wording implicitly allows for there being multiple non-free areas. >I know that's not how we're currently reading it, and probably not how it >was intended, but one can interpret the same sentence as saying there is >one or more contrib area and one or more non-free area. > >I like that a little better since it avoids having to update a foundation >document for what's essentially bookkeeping. Suppose, for example, that >we want to split out some other bit of non-free in the future for some >non-SC-related reason (contrib or non-free debug symbols or whatever). It >feels weird to have to amend the SC just to add the new name to a list. Right. Maybe it might be helpful to tweak the wording the *other* way then, something like: We have created extra areas in our archive for these works. so we don't specify the areas explicitly? Just a thought... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
On Wed, Sep 07, 2022 at 10:48:36AM -0700, Russ Allbery wrote: >Between one thing and another I've not been tracking the timeline of this >vote and I'm worried we may be out of time for new ballot options and >possibly extensions. > >(As promised in the previous vote for changing the timing of GRs, I've >been watching the timing closely and the last couple have felt rushed. >When there's a quiet period, I'm considering proposing a small >constitutional amendment to relax the timelines a bit based on that >experience. But we can discuss that separately.) > >If there is time left, though, I'm considering proposing the following >option based on my earlier message, just so that there's something on the >ballot that explicitly modifies the Social Contract to allow for non-free >firmware, in case people want that for clarity. > >I should stress that I'm not involved in this part of Debian directly and >am not a great choice for a proponent, so I'd be happy if someone else >took that over, but it does feel to me like it would be good to have this >explicitly on the ballot. > >Possible wording, which includes the existing option A verbatim: > >-- > >This ballot option supersedes the Debian Social Contract (a foundation >document) under point 4.1.5 of the constitution and thus requires a 3:1 >majority. > >The Debian Social Contract is replaced with a new version that is >identical to the current version in all respects except that it adds the >following sentence to the end of point 5: > >The Debian official media may include firmware that is otherwise not >part of the Debian system to enable use of Debian with hardware that >requires such firmware. > >The Debian Project also makes the following statement on an issue of the >day: > >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. Where non-free firmware is found to be >necessary, 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. Thanks Russ! Seconded. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Wed, Sep 07, 2022 at 08:31:34PM +0200, Bart Martens wrote: >On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote: >> I think the problem is with "non-free section". I think Steve looks at >> that like the non-free-firmware section is now allowed. I suggest you >s/now/not/ >> just rewrite it as: "containing non-free software from the Debian >> archive". > >Hi Kurt, > >Yes, let's do that, thanks. So here is the adapted proposal C: > >= > >The Debian project is permitted to make distribution media (installer images >and live images) containing non-free software from the Debian archive available >for download alongside with the free media in a way that the user is informed >before downloading which media are the free ones. > >===== Thanks Bart, I'm much happier with this. Seconded. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross signature.asc Description: PGP signature
Re: Requesting Extension (was: Re: Changing how we handle non-free firmware)
On Wed, Sep 07, 2022 at 06:26:29PM +0200, Jonathan Carter (highvoltage) wrote: >Dear Debian Secretary and Debian Developers > >As 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. Thanks Jonathan! Let's make good use of the extra time to fine-tine the ballot. -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Wed, Sep 07, 2022 at 08:24:33AM +0200, Bart Martens wrote: >On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote: >> >> I think the problem is with "non-free section". I think Steve looks at >> that like the non-free-firmware section is now allowed. I suggest you >> just rewrite it as: "containing non-free software from the Debian >> archive". > >Steve, would this idea from Kurt bring you back? Yes, that's much better. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Tue, Sep 06, 2022 at 11:56:23PM +0200, Bart Martens wrote: >On Tue, Sep 06, 2022 at 08:25:44PM +0100, Steve McIntyre wrote: >> >> No, it doesn't. > >> Your words may cover where those packages are *today*, > >Exactly. > >> but they most likely will *not* be in "non-free" when we come to make >> the changes. "non-free-firmware" != "non-free". > >I understood that part. > >> Please tweak your >> wording to be more flexible and cover what we're aiming to do. > >I think we have a different view on which proposal is the most flexible. And I >understand that you want my proposal to cover what you are aiming at. Bart, I genuinely don't understand why you're so wedded to this specific wording even after multiple people have tried to explain the problems they see here. Do you have a particular beef with the non-free-firmware section? As written, I believe your ballot option will cause more confusion and problems down the line. Therefore, regretfully I have to withdraw my seconding of your ballot option. -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote: >On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote: >> On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote: >> >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote: >> >> > I hereby propose the following alternative text to Steve's original >> >> > proposal. >> >> > >> >> > = >> >> > >> >> > The Debian project is permitted to make distribution media (installer >> >> > images >> >> > and live images) containing packages from the non-free section of the >> >> > Debian >> >> > archive available for download alongside with the free media in a way >> >> > that the >> >> > user is informed before downloading which media are the free ones. >> >> > >> >> > = >> >> >> >> Wondering if this should be s/non-free section/non-free-firmware section/ >> > >> >Thanks for asking. The short answer is no. I kept my proposal very short, >> >keeping the focus on the smallest possible action we can do for helping >> >those >> >users that need non-free firmware: allowing ourselves to advertise non-free >> >installers just as visible as our free installer. Moving non-free firmware >> >to a >> >separate section might be useful, but it is in my view not part of that >> >smallest possible action. So what's my position on such new section? Well, >> >what >> >is not mentioned is not proposed and not opposed. That's all. - B. >> >> Argh. So this does *not* work with the plan that we have *already >> started*, where we're going to move firmware things to >> non-free-firmware instead. Please switch to "non-free and/or >> non-free-firmware sections" in your text. > >I'm surprised. Please read what is written. Proposal C leaves open whether such >new section would be added in the future. So if proposal C would win, then the >started work you describe can continue. Proposal C uses the term "non-free" >because that is where all non-free packages are still residing today. > >Does this cover your concern? No, it doesn't. Your words may cover where those packages are *today*, but they most likely will *not* be in "non-free" when we come to make the changes. "non-free-firmware" != "non-free". Please tweak your wording to be more flexible and cover what we're aiming to do. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote: >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote: >> > I hereby propose the following alternative text to Steve's original >> > proposal. >> > >> > = >> > >> > The Debian project is permitted to make distribution media (installer >> > images >> > and live images) containing packages from the non-free section of the >> > Debian >> > archive available for download alongside with the free media in a way that >> > the >> > user is informed before downloading which media are the free ones. >> > >> > = >> >> Wondering if this should be s/non-free section/non-free-firmware section/ > >Thanks for asking. The short answer is no. I kept my proposal very short, >keeping the focus on the smallest possible action we can do for helping those >users that need non-free firmware: allowing ourselves to advertise non-free >installers just as visible as our free installer. Moving non-free firmware to a >separate section might be useful, but it is in my view not part of that >smallest possible action. So what's my position on such new section? Well, what >is not mentioned is not proposed and not opposed. That's all. - B. Argh. So this does *not* work with the plan that we have *already started*, where we're going to move firmware things to non-free-firmware instead. Please switch to "non-free and/or non-free-firmware sections" in your text. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Fri, Sep 02, 2022 at 09:14:53PM +0200, Kurt Roeckx wrote: >On Tue, Aug 30, 2022 at 03:11:25PM -0500, Richard Laager wrote: >> >> > I like to discussion about anything related to this, so that I can at >> > least get an idea what the consensus is. >> >> DSC 1 and DSC 5 have some implications about "the Debian system" vis-a-vis >> non-free, but the plan here is to keep the firmware in a separate >> non-free-firmware analogous to non-free. That seems fine to me. >> >> DSC 1 says we will never "require the use of a non-free component". To me, >> this is the major relevant issue. >> >> Proposals B and C offer users the explicit choice of media. That feels >> clearly compatible with the DSC, as users are not required to use non-free >> bits. >> >> Proposal A will use non-free-firmware by default, but "where possible...will >> include ways for users to disable this". Without the "where possible", I >> think this opt-out is compatible with the DSC. However, if it is not >> possible to disable the non-free-firmware, then it feels like the system is, >> in fact, requiring it. Thus this option, as worded, feels potentially >> incompatible with the DSC. > >It that it says "at boot". That seems to imply that it will get >installed, but it might not get used, which might at least surprise >some people. But maybe that's only for the live images. I don't think we're on the same page here. The point of "at boot" and "where possible" here is just to describe possibilities for how users would interact with the firmware-included media. For example: if a user selected a boot option saying "use no non-free firmware, then it would be neither used *nor* installed. I added "where possible" as I can't state with *100%* certainty that we'd be able to expose that choice in every possible boot method - we haven't worked through all the possibilities yet! If those bits of extra text are causing you problems, then let's remove them? >Note that the SC only says: "require the use of a non-free component". >This can be interpreted as having it installed is not a problem as >long as it's not used. > >I think there are people that want to use the official image but don't >want anything non-free installed, nor want it in the sources.list file. >So they might want to have an installer that supports that. > >So I think I have to agree that the "where possible" is probably not >compatible with the SC. I think it should be more explicit that it will >be possible to disable the use of non-free firmware. Right. See above... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Hey guys, Apologies for not responding more promptly on this sub-thread :-/ On Mon, Sep 05, 2022 at 09:51:24PM +0200, Kurt Roeckx wrote: >On Sun, Sep 04, 2022 at 08:00:48PM -0500, Richard Laager wrote: ... >> [1] I understand that your (the Secretary's) current position is that you do >> not have the power to interpret Foundation Documents. I contend that you >> implicitly do, at least insofar as such an interpretation is required to >> fulfill one of your explicit duties. If you do not, then it seems the >> Project Leader would, through a combination of 5.1.3 (requires urgent >> action) and/or 5.1.4 (noone else has responsibility). > >As part of this GR, I'm just trying to make sure you can interpret the >SC in a consistent way that matches the ballot option. > >Thank you for discussion this, I wish more people would participate in >this. Would you be more comfortable if we added an extra option like Russ suggested [1], explicitly adding extra text to the SC? [1] https://lists.debian.org/debian-vote/2022/08/msg00182.html -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Wed, Aug 31, 2022 at 05:50:17PM +0200, Bart Martens wrote: >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote: >> 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. > >This means that non-free-firmware would be always enabled, also when the system >would not determine that the included firmware binaries are required. Intended? After a suggestion from Wouter I've agreed a change here for exactly that reason - see Message-ID: <20220830200050.gz2668...@tack.einval.com> yesterday. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Re: Changing how we handle non-free firmware
On Tue, Aug 30, 2022 at 04:27:17PM -0400, Antoine Beaupré wrote: >On 2022-08-30 21:11:07, Steve McIntyre wrote: >> >> But I want to be *very* clear here that we *don't* want to enable the >> whole of the non-free component for all users by default. That would >> be a grave disservice, and I think Ansgar agrees with me. There's no >> need to hold this back to be part of the GR here IMHO. > >Yeah, so I think that's a great advantage of splitting firmware out of >non-free: it keeps the "non-free blast radius" to a minimum, just to >make sure people can get their hardware working without getting all that >other stuff that they should really opt into. > >Yet I actually use non-free for other stuff as well, at a personal >level. Things like documentation, for example, often end up in non-free >for $reasons and I have non-free enabled for *both* this and firmware. > >In that sense, why wasn't it possible to have (say) non-free/firmware as >a component, so that when you opt-in to non-free you *also* get >firmware? That would have been a backwards-compatible change... I genuinely am not sure how various tools will interact with that kind of change to have nested components, tbh. I'd rather be clean and consistent here, and I believe Ansgar agrees. Similarly that's why the new non-free-firmware component has no special handling to try and and override package uploads there. Special cases suck, particularly as/when/if they stack on top of each other... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Hey Russ! On Mon, Aug 29, 2022 at 07:55:11PM -0700, Russ Allbery wrote: >Kurt Roeckx writes: > >> It's my current interpretation that all voting options, even if they >> might conflict with the DSC, will be on the ballot, and might not >> require a 3:1 majority. That is, I don't think the Secretary can decide >> not to include an option that might conflict, or put a 3:1 majority >> requirement on it because they think it conflicts. > >I'm not disagreeing with Kurt's interpretation here, but as a voter I >would love for one of the proponents of a ballot option to add non-free >firmware to the installer to state that they are going for a 3:1 majority >to modify the Social Contract and add an explicit statement to this effect >to point 5 of the Social Contract. It would only take a sentence, I >suspect, something like: > >The Debian installer may include firmware that does not conform to the >Debian Free Software Guidelines to enable use of Debian with hardware >that requires such firmware. If you were to propose an alternative to option A that added a 3:1 majority change to patch the SC, I would happily second it. But I certainly don't personally feel strongly enough about that change to propose it myself. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html signature.asc Description: PGP signature
Re: General resolution: non-free firmware
On Tue, Aug 30, 2022 at 08:28:15PM +, Thorsten Glaser wrote: >Steve McIntyre dixit: > >>You've utterly missed Phil's point about people not seeing or hearing >>boot options. > >I didn’t. I pointed out that people can select different bootloader >options if their bootloader is already set up for them, or that they >can pre-create different images with nōn-free-firmware enabled if not. OK, apologies. You haven't missed it. Instead you seem to want to make a blind user have to do extra work before they even start doing an installation? That's not exactly a helpful first introduction, is it? >>Go and read my first mail in the thread for context. > >https://lists.debian.org/debian-vote/2022/08/msg1.html > >That? It doesn’t at all address the bootloader. It *exactly* says why I want to enable use of the non-free by default: """ 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. """ -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Changing how we handle non-free firmware
On Tue, Aug 30, 2022 at 09:22:39AM +0200, Simon Josefsson wrote: >Steve McIntyre writes: ... >>>Thereby re-inforcing the interpretation that any installer or image with >>>non-free software on it is not part of the Debian system, but that we >>>support their use and welcome others to distribute such work. >>> >>>== >> >> This last bit of wording is slightly unclear to me. Should *Debian* be >> allowed to distribute an installer or image with non-free software on >> it? > >Hi Steve. I'm not sure I can reliably answer -- the distinction between >"Debian" as the project and "Debian" as the operating system is (for me) >somewhat blurry and inconsistent throughout the current foundational >documents, and it is equally unclear (to me) in your question. > >Do you intend the Debian OS (which to me includes various installers and >other auxilliary software that is needed to produce and maintain an OS) >or the Debian project (which to me is about the community and not the >deliverable)? Or is your understanding of the situation different than >mine so your question really mean different things to us? I have a >feeling that is the case, but it is subtle. To me, saying "we support their use and welcome others to distribute such work" has an *implicit* suggestion that "the Debian project will not distribute such work itself". I could be reading more into that than was intended, so I thought it was worth checking! :-) >I believe it used to be better in the older social contract which used >'Debian GNU/Linux' in a couple of places which made it clear that the >sentence referred to the deliverable and not the community. That was >lost a couple of years ago, replacing it with 'Debian' which makes it >unclear what it refers to. The website has been similary modified >throughout the years, leading to the same ambiguity. > >Speaking personally (and thus merely as an anecdote), my way to resolve >this conflict (when I belatedly decided to join as DD) has been that >'Debian' as an OS is promised to be 100% DFSG free but 'Debian' as a >project will accept to distribute certain non-free material on its >servers. Thus Debian can be labeled as a 100% free OS but Debian as a >project deals with non-free content but not as a first-class citizen. >This has lead to forks that don't want to be stuck with the same dilemma >-- Ubuntu/etc as a non-free variant and gNewSense/PureOS/etc as a free >variant. This inconsistency may continue to be both a curse and a >blessing, allowing Debian to be relevant to both worlds. Right, thanks for clarifying here! >I agree with you that improving clarity on this topic will be a good >thing. Fixing that is outside of my current goals though, as what I >want to achieve is to see Debian continue to deliver a 100% DFSG-free >Debian OS. It makes me sad to see such efforts to stop that. ACK, understood. It doesn't make me happy *either* that we're in this situation, but there are often tradeoffs to be made where we collide with the outside world. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed? signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Hey Antoine! On Tue, Aug 30, 2022 at 11:33:15AM -0400, Antoine Beaupré wrote: ... >I particularly want to salute your work on making our users actually >capable of using more modern hardware. I think the proposal you bring up >(and the others that were added to the ballot) will really help move >this problem ahead. I'm actually quite happy with how the conversation >went so far, it seems we have matured quite a bit in our capacity in >handling difficult decisions such as this one. Yes, definitely! I've been very happy that we can talk about potentially divisive topics in a reasonable fashion. :-) >> Since I started talking about 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! :-) > >This, however, strikes me as odd: I would have expected this to be part >of the proposal, or at least discussed here, not implemented out of band >directly. I happen to think this is a rather questionable decision: I >would have prefered non-free to keep containing firmware images, for >example. Splitting that out into a different component will mean a lot >of our users setup will break (or at least stop receiving firmware >upgrades) unless they make manual changes to their sources.list going >forward. This feels like a regression. So we'll need to advertise it well so that people pick these changes up. That's important. But I want to be *very* clear here that we *don't* want to enable the whole of the non-free component for all users by default. That would be a grave disservice, and I think Ansgar agrees with me. There's no need to hold this back to be part of the GR here IMHO. >In general, I feel we sometimes underestimate the impact of sources.list >changes to our users. I wish we would be more thoughtful about those >changes going forward. It seems like this ship has already sailed, of >course, but maybe we could be more careful about this in the future, >*especially* since we were planning on having a discussion on >debian-vote about that specific issue? ACK, I understand. >> 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. > >Gulp, such a big jump! :) I personnally feel that we should make it >easier for people to install Debian, but I'm not quite sure I'm ready to >completely ditch the free images just yet. Maybe we could just promote >non-free images a little better, but I would much rather keep the free >images around. I guess that makes me a supporter of option "B", if I >understand correctly, but I am known for struggling with parsing GR >proposals. :) Nod, that's fair! I proposed option A as my personal favourite for the GR to remove (YA) possible point of confusion for our users, but I'm definitely not blind to the size of the change that it makes for us. Option B definitely sounds like a preferred option for some, and I'm OK with that. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Hi Kurt! Let's send this signed now, On Sat, Aug 27, 2022 at 04:26:40PM +0200, Kurt Roeckx wrote: >On Fri, Aug 19, 2022 at 11:26:51AM +0100, Steve McIntyre wrote: >> Hey Wouter! >> >> On Fri, Aug 19, 2022 at 12:19:55PM +0200, Wouter Verhelst wrote: >> >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote: >> >> system will *also* be configured to use the non-free-firmware >> >> component by default in the apt sources.list file. >> > >> >What's the rationale for this one? >> > >> >I think it would make more sense to only configure the system to enable >> >the non-free-firmware component if the installer determines that >> >packages from that component are useful for the running system (or if >> >the user explicitly asked to do so). >> >> That's a fair point, my text was unclear here. Let's tweak it: >> >> "Where non-free firmware is found to be necessary, the target system >> will *also* be configured to use the non-free-firmware component by >> default in the apt sources.list file." >> >> Does that sound better? > >Is this something you want to adopt? Yes, I think it improves things. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Hi Bart! On Tue, Aug 30, 2022 at 09:12:23PM +0200, Bart Martens wrote: >On Mon, Aug 29, 2022 at 09:49:14PM +0100, Steve McIntyre wrote: >> Hi Simon! >> >> On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote: > >> > >> >Thereby re-inforcing the interpretation that any installer or image with >> >non-free software on it is not part of the Debian system, but that we >> >support their use and welcome others to distribute such work. >> > >> >== >> >> This last bit of wording is slightly unclear to me. Should *Debian* be >> allowed to distribute an installer or image with non-free software on >> it? > >Debian already does that. Anything available for download on *.debian.org is in >fact distributed by Debian. The label "unofficial" doesn't change that. >My point is that the last paragraph in Simon J's proposal correctly reflects >the current reality. (But I fail to see the value of Simon J's proposal on the >ballot because it is in my understanding equivalent with "further discussion" / >"none of the above" which is already on the ballot.) I'm directly asking Simon for *his* thoughts here, though. It's *not* necessarily the same as the status quo, and I think this needs to be explored more. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Hi Simon! On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote: > >== > >We continue to stand by the spirit of the Debian Social Contract §1 >which says: > > Debian will remain 100% free > > We provide the guidelines that we use to determine if a work is > "free" in the document entitled "The Debian Free Software > Guidelines". We promise that the Debian system and all its components > will be free according to these guidelines. We will support people > who create or use both free and non-free works on Debian. We will > never make the system require the use of a non-free component. > >Therefore 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. > >We also continue to stand by the spirit of the Debian Social Contract §5 >which says: > > Works that do not meet our free software standards > > We acknowledge that some of our users require the use of works that > do not conform to the Debian Free Software Guidelines. We have > created "contrib" and "non-free" areas in our archive for these > works. The packages in these areas are not part of the Debian system, > although they have been configured for use with Debian. We encourage > CD manufacturers to read the licenses of the packages in these areas > and determine if they can distribute the packages on their CDs. Thus, > although non-free works are not a part of Debian, we support their > use and provide infrastructure for non-free packages (such as our bug > tracking system and mailing lists). > >Thereby re-inforcing the interpretation that any installer or image with >non-free software on it is not part of the Debian system, but that we >support their use and welcome others to distribute such work. > >====== This last bit of wording is slightly unclear to me. Should *Debian* be allowed to distribute an installer or image with non-free software on it? -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Re: Changing how we handle non-free firmware
Hi Kurt! On Sat, Aug 27, 2022 at 04:26:40PM +0200, Kurt Roeckx wrote: >On Fri, Aug 19, 2022 at 11:26:51AM +0100, Steve McIntyre wrote: >> Hey Wouter! >> >> On Fri, Aug 19, 2022 at 12:19:55PM +0200, Wouter Verhelst wrote: >> >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote: >> >> system will *also* be configured to use the non-free-firmware >> >> component by default in the apt sources.list file. >> > >> >What's the rationale for this one? >> > >> >I think it would make more sense to only configure the system to enable >> >the non-free-firmware component if the installer determines that >> >packages from that component are useful for the running system (or if >> >the user explicitly asked to do so). >> >> That's a fair point, my text was unclear here. Let's tweak it: >> >> "Where non-free firmware is found to be necessary, the target system >> will *also* be configured to use the non-free-firmware component by >> default in the apt sources.list file." >> >> Does that sound better? > >Is this something you want to adopt? Yes, I think it improves things. >Would a non-free-firmware section in the archive be useful, so >that other non-free software is not enabled by default? Definitely, that's an important feature here IMHO. We already have that new section available, it's just not supported everywhere yet. -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone
Re: Changing how we handle non-free firmware
On Wed, Aug 24, 2022 at 09:40:24AM +0800, Paul Wise wrote: > >The problem is that the vendors for most devices that include the Intel >hardware require Intel signatures on the firmware binaries. > >Some devices (Intel based Chromebooks and UP boards) allow firmware >binaries to be signed by a "community" private key that is public. > >In the future Intel may enable a scenario similar to Secure Boot's >Machine Owner Key setup, where device owners can add new signing keys. > >https://github.com/thesofproject/sof/issues/5814 > >In that situation, Debian could sign the audio firmware binaries >instead and allow users to sign their own modified firmware binaries. Yup, that would be a lovely big win! >> The free installer is ideal for virtualisation only because it's >> sitting on top of a bunch of idealised hardware. > >It could also be useful for devices that run libre firmware, such as >Raptor Computing's ppc64el devices, although Debian does not have >packages of the libre firmware projects for these devices so in >practice it isn't yet useful for those scenarios. Right. I'd prefer us not to get dragged down the "users just need to pick the right hardware" path. That way potentially lies a (slightly snobbish?) "you chose wrong, try harder" message that will just push users (and eventually developers) to other distros. There are always going to be machines that we can't/won't be able to support, but when the vast majority of current laptops don't function sensibly without non-free firmware I think we have to adapt to reality in supporting our users. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Re: Changing how we handle non-free firmware
On Tue, Aug 23, 2022 at 05:51:46PM -0400, Tiago Bortoletto Vaz wrote: >On Tue, Aug 23, 2022 at 11:20:09PM +0200, Bart Martens wrote: >> On Tue, Aug 23, 2022 at 03:33:27PM +, Holger Levsen wrote: >> > On Tue, Aug 23, 2022 at 05:04:49PM +0200, 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"? >> >> It would be nice to have both installers presented on the front page, so >> users >> can choose. I have no strong opinion on whether the "plus" installer would be >> called official or not. > >Same here. I've seconded Gunnar's proposal because it's the one which adds the >option. However, referring to it as official is not something I'm fully >comfortable at this point. ACK. >I'm wondering how the d-i team feels about that (having the image with non-free >bits called unofficial). Or whether it makes any sense at all, say, having such >an essential component developed by fellow Debian members, using official >Debian resources, and still being named 'unofficial', just for our convenience >(?) Well, when we started making the "firmware-included" images it seemed like a clear way to separate them from the *official* free images. It's a bit like having non-free included on ftp.debian.org - we push things to a slightly different area. We already had the "unofficial" area on cdimage.debian.org as a catch-all for other media, so I just added a new unofficial/non-free tree there. >Btw, thanks Steve and all involved on this front, I'm just a bit confused and >appreciating the discussion. Cool. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Changing how we handle non-free firmware
On Wed, Aug 24, 2022 at 10:12:48AM +0200, Bart Martens wrote: >Hello, > >I hereby propose the following alternative text to Steve's original proposal. > >= > >The Debian project is permitted to make distribution media (installer images >and live images) containing packages from the non-free section of the Debian >archive available for download alongside with the free media in a way that the >user is informed before downloading which media are the free ones. > >= Seconded! Thanks for this, I'm happy to see sensible alternatives for the GR! -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
Hey Ross! On Wed, Aug 24, 2022 at 11:36:00AM -0700, Ross Vandegrift wrote: > >Thanks for this. I have two questions about your proposal. Apologies >if these are answered elsewhere already. No worries. >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote: >> I'm proposing to change how we handle non-free firmware in >> Debian. > >> 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.). > >First question: > >The substantial issue here that requires a GR is the treatment of >non-free-firmware packages. The bits about installation media are kind >of fallout, or implementation details. It might be better to leave >those out of the GR, and just get crystal clear on the project's >treatment of non-free firmware. I'm not sure I agree with you here. We already have firmware packages in the non-free component of the archive. Ansgar's work on dak has added a new non-free-firmware component, and the plan is that we'll start moving some packages across there soon. For a long time we've said (*handwave*) that non-free is not really part of Debian, so we're not compromising our principles. I don't particularly care about the details of that piece right here and now. The issue I want solved here in the GR is *precisely* what we're going to do about Debian-produced media: * installation media * live images (both traditional "live" images for x86, and the newer raspi images) * (*potentially*) cloud and container images; they're not likely to use non-free firmware, and I hope it stays that way. But you never know... We currently have two sets of installation media and live images: * "official" ones without anything from non-free, that are entitely free and could live in Debian main, *but* are not useful for use and/or installation on lots of current machines these days. * "unofficial" ones which include firmware packages from non-free, but no other non-free packages. These are more useful for many people, but are not fully DFSG-free. The raspi images live in this area, as most of the raspi hardware depends on a non-free primary bootloader that can't love in Debian main. with the latter set not as well publicised. That's not a great story. So I'm describing exactly what we want to change in our images such that: * it's clear we'll be adding non-free-firmware * we're explaining how it will be used, and how users can control that That may sound like implementation details to you, but to me those are the important parts of the change. I'd rather not be in this position, and I have a lot of sympathy for the people pushing back on the idea of maybe compromising our Freeness. This is why I want to spell it out clearly. >Would you feel empowered to implement your changes if the GR passed >without these implementation details? That is, if we voted to permit >non-free-firmware packages on official installation media, live images, >and default installations. I'm not sure that really makes much difference here, I'll be honest? >Second question: > >It might be good to have rules spelling out what can go into >non-free-firmware. This would help clarify how non-free-firmware isn't >just non-free. Is this in place or in progress? Does the GR need to >include it, or is there some other appropriate mechanism? A few of us have spoken about it, but it's not something that we've laid down in stone yet. We're looking at packages that install only non-free binary blobs in /lib/firmware, containing only firmware / software that executes separately to the control of the main OS. So, that includes things like firmware for wifi hardware *and* CPU microcode, but *not* (e.g.) the non-free Nvidia drivers that integrate with the OS kernel. I'm less worried about this side - AFAICS ftpmaster and the the people already packaging these things already have a reasonable idea on what goes where. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Re: Changing how we handle non-free firmware
Hi Bart! On Tue, Aug 23, 2022 at 10:22:39PM +0200, Bart Martens wrote: >On Mon, Aug 22, 2022 at 11:32:23AM -0500, Gunnar Wolf 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. Sure, we can add explanatory text here. But in terms of recommending one, *whether we say it explicitly or not* one will get more downloads and users than the other. Most likely the first one listed on the download page, just *because*. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Changing how we handle non-free firmware
Hey Phil, Thanks for writing this, I think you're explaining this well. Except...! On Tue, Aug 23, 2022 at 12:51:10PM +0200, Philip Hands wrote: > >I would suggest that "abandoning the free software ideals of the Debian >project" is significantly mis-characterising what's going on here. > >Debian has always been pretty pragmatic about enabling the use of >non-free software by our users, even while maintaining the strict >separation of non-free from main. > >That is after-all what's kept the FSF mildly upset with us all these >years. I don't suppose that including non-free-firmware on our ISOs >will help with that, but it also doesn't really make things any worse. > >By not having the non-free-firmware on our media, we really do lose new >users, all the time. > >In particular, people that don't have any choice regarding their >hardware often fail to install anything useful with our 100% pure ISOs. > >Those people are likely to have obtained some old hardware either as a >gift or very cheaply, and do not have a budget for an RFY wifi stick. > >Debian with the non-free drivers often runs really well on such >hardware, giving people that would otherwise be digitally excluded a >viable option. We're talking about non-free **firmware, not non-free **drivers**. Sorry to play the pedant card here (and I know you know the difference!), but this is a common mistake and a lot of users really get the two confused. >Encouraging such people to waste their efforts downloading an ISO that >we know is quite likely to fail for them, while hiding the image we know >they really need strikes me as a form of abuse. > >A lot of people will abandon the attempt after a single failure. > >Every one of these lost users is a potential Debian contributor. Driving >them away is an act of self-harm, and does more damage to Free Software >than could possibly be done by admitting the truth that for many >(newbies in particular) the tainted ISOs are what people really want. > >There will be plenty of time to explain that their they should choose a >better wifi card if they get the chance once they have managed their >first install, but if we continue to set up obstacles at the start then >they won't even be around to listen. *nod* Exactly. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Changing how we handle non-free firmware
On Tue, Aug 23, 2022 at 11:47:34AM +0800, Paul Wise wrote: >On Mon, 2022-08-22 at 12:32 -0500, Gunnar Wolf wrote: > >> I'm only suggesting to modify the third paragraph, offering to produce >> two sets of images (fully-free and with-non-free-firmware), being the >> later more prominent. > >Is the Debian Images team willing to continue to produce the images >containing only packages from main? > >I understood from the initial blog post they aren't willing to do that. I'd personally rather *not* do that, but if that'w what the project wants then it'll happen. The amount of extra work is not huge; we're already doing similar with the second set of non-free images anyway. I'm more interested in streamlining the choice for the sake of users, tbh. >I wouldn't want Debian to vote for them to work on fully-free images if >they still don't want to do that, so I'm not sure of the practicality >of this proposal and so I would find it hard to rank it on the ballot. > >PS: this seems similar to but less detailed than my earlier proposal: > >https://lists.debian.org/msgid-search/683a7c0e69b081aae8c46bd4027bf7537475624a.ca...@debian.org It's similar, agreed. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: Changing how we handle non-free firmware
Thanks Gunnar, I'm happy that somebody has suggested another option for a ballot! On Mon, Aug 22, 2022 at 12:32:54PM -0500, Gunnar Wolf wrote: >I hereby propose the following alternative text to Steve's original >proposal. > >I'm only suggesting to modify the third paragraph, offering to produce >two sets of images (fully-free and with-non-free-firmware), being the >later more prominent. > >= > >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. > >While we will publish these images as official Debian media, they will >*not* replace the current media sets that do not include non-free >firmware packages, but offered alongside. Images that do include >non-free firmware will be presented more prominently, so that >newcomers will find them more easily; fully-free images will not be >hidden away; they will be linked from the same project pages, but with >less visual priority. > >= Seconded. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Mon, Aug 22, 2022 at 11:32:23AM -0500, Gunnar Wolf wrote: >Bart Martens dijo [Mon, Aug 22, 2022 at 06:24:32PM +0200]: >> >> We'd take away the free installer. > >If a free installer is still produced and offered alongside the one >including non-free-firmware, would you feel more at ease? That sounds >like an easy compromise to make, and many people would probably >welcome it. > >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. Absolutely! As I said in the first mail in this thread: please suggest alternatives that you might prefer. I'm fully hoping and expecting that we will have a few alternatives on the GR ballot here, so as a project we can choose our preferred way forward. I mainly held back from suggesting other options muself because of advice in the d-devel thread. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Re: Changing how we handle non-free firmware
Hey Wouter! On Fri, Aug 19, 2022 at 12:19:55PM +0200, Wouter Verhelst wrote: >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote: >> system will *also* be configured to use the non-free-firmware >> component by default in the apt sources.list file. > >What's the rationale for this one? > >I think it would make more sense to only configure the system to enable >the non-free-firmware component if the installer determines that >packages from that component are useful for the running system (or if >the user explicitly asked to do so). That's a fair point, my text was unclear here. Let's tweak it: "Where non-free firmware is found to be necessary, the target system will *also* be configured to use the non-free-firmware component by default in the apt sources.list file." Does that sound better? >If I'm not mistaken, code to do this already exists, and seems to work >well (but do correct me if I'm wrong). Ish! :-) We don't have any code in d-i to deal with the *non-free-firmware* component yet, but I#m sure we can adapt the existing stuff around non-free / contrib to suit. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Re: Changing how we handle non-free firmware
Hi Iain! On Fri, Aug 19, 2022 at 10:34:20AM +0100, Iain Lane wrote: >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote: >> = >> >> 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. >> >> = > >Seconded. > >As a potential tweak: > >The text says that we will include ways to disable this at *boot time*; >how about being explicit that we will provide ways to disable at >*installation time* too? Arguably this is implied by '[t]he target >system will *also* be configured to use the non-free-firmware component >_by default_ …' already but I think we could stand to be more concrete >about that. Hmmm, maybe. To clarify: are you thinking about: * adding an option to not install the firmware while the installation happens; or * adding a (boot?) option to not load it once the new system is installed and booted ? I'm not sure the latter is much use, so I'm thinking you mean the former. I think we can do that (in expert mode / low-prio debconf question?) as part of what we're looking at, but I'm not 100% sure it necessarily has to be spelled out in this much detail in the GR? -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Changing how we handle non-free firmware
Hey Timo! On Thu, Aug 18, 2022 at 10:18:13PM +0300, Timo Lindfors wrote: >On Thu, 18 Aug 2022, Steve McIntyre wrote: >> 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]. > >Thanks for working on this somewhat controversial topic. I haven't spend that >much time thinking about the issue yet but perhaps the following steps could >help make this less controversial: > >1) As it is pretty impossible to write a clear definition of > firmware, we should require packages in non-free-firmware to clearly > explain where the code will get executed to allow people to make > informed decisions. Some people are more ok with having code run on > an external device than on the main CPU. Sure, that sounds like a reasonable thing to do as part of the "information about the firmware step"! >2) Ensure that the installer will inform users about non-free-firmware > packages that are about to be installed and possibly also allow the > user to see their full description. That's a hard one to do reliably - see my example of a biind user needing audio firmware to be able to interact with the installer. That's a real case that Samuel Thibault has worked on. Of course we want to give people the information, but in some cases we may have to choose to load the firmware *before* asking. >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. > >4) If at all possible, keep the fully free installation media available as > was already suggested earlier. These two are separate options IMHO - see my initial blog post. If you want to write them up, I imagine that you will quite easily get seconds here. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Changing how we handle non-free firmware
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't great. 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 about 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 -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... signature.asc Description: PGP signature
Re: General Resolution: withdraw defamation and WIPO action, recognize all Debian Developers are equal as co-authors
Daniel, go away. You and your sockpuppets are not welcome here and you know it. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Question to all candidates: Ongoing/future legal projects
On Fri, Mar 18, 2022 at 11:08:33AM -0700, Felix Lechner wrote: >Hi Steve, > >On Fri, Mar 18, 2022 at 10:48 AM Steve McIntyre wrote: >> >> Which would you be prepared to provide as DPL? > >Whichever the members perceive as proper. Which do *you* perceive as proper? Come on, please stop evading the question. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: https://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Re: Question to all candidates: Ongoing/future legal projects
On Fri, Mar 18, 2022 at 10:43:49AM -0700, Felix Lechner wrote: >Hi Steve, > >On Fri, Mar 18, 2022 at 10:19 AM Steve McIntyre wrote: >> >> Hmmm.. Do you not feel that project should stand with and support >> contributors facing harassment because of their work in Debian? > >Are you asking for empathy or for financial assistance? Which would you be prepared to provide as DPL? -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: Question to all candidates: Ongoing/future legal projects
Hi Felix, On Fri, Mar 18, 2022 at 08:23:12AM -0700, Felix Lechner wrote: > >The harassment case is easily distinguished in that (1) the victim >seeks to initiate legal action instead of needing help with a defense, >and (2) the project's survival is not at risk—unless the victim sues >Debian as well. Hmmm.. Do you not feel that project should stand with and support contributors facing harassment because of their work in Debian? -- Steve McIntyre, Cambridge, UK.st...@einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier
Re: GR: Hide Identities of Developers Casting a Particular Vote
varied by up
> to 1 week by the Project Leader.
>
>
>
>@@ -247,7 +266,7 @@ earlier can overrule everyone listed later.
>
>
>
>Votes are cast[-by email-] in a manner suitable to the Secretary.
>The Secretary determines for each poll whether voters can change
>their votes.
>
>@@ -371,8 +390,7 @@ earlier can overrule everyone listed later.
> necessary.
>
> The next two weeks are the polling period during which
> Developers may cast their votes. [-Votes in leadership elections are-]
>[- kept secret, even after the election is finished.-]{++}
>
> The options on the ballot will be those candidates who have
> nominated themselves and have not yet withdrawn, plus None Of The
--
Steve McIntyre, Cambridge, UK.st...@einval.com
“Why do people find DNS so difficult? It’s just cache invalidation and
naming things.”
-– Jeff Waugh (https://twitter.com/jdub)
signature.asc
Description: PGP signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
On Thu, Feb 17, 2022 at 10:07:18AM +0100, Enrico Zini wrote: > >I like that a number of options have been brainstormed in the >discussion: secret ballots, ballots secret on request, ballots public on >request, ballots disclosed only to Debian Members, public ballots. I >like a GR with a range of options. Absolutely - there are a lot of reasonable options here, and let's hear them all. >Thank you for driving this! +1 -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
Felix... On Mon, Feb 14, 2022 at 10:42:43AM -0800, Felix Lechner wrote: > >All of them were condemned by later generations: the Salem witch hunt; >McCartyism; the cultural revolution in China; collectivisation under >Pol Pot in Cambodia; and perhaps most infamously the many attempts >over time to expel or eradicate the Jews from various territories. > >The collective condition that leads to such madness is now well >understood. It is a group form of splitting and projection [1] that >affects entire societies. The phenomenon is easily recognized once you >understand it. Because of the extreme danger, Orthodox Jews teach it. >[2] > >One of Germany's great insights after World War II was that all calls >for social upheaval are in themselves barbaric. The country now has >special local and federal police agencies to monitor such corrosive >speech (Verfassungsschutz). > >In 1949, Arthur Miller wrote the play "The Crucible" about it. He won >a Pulitzer and many other accolades. In 1954, William Golding dealt >with similar group dynamics in the novel "The Lord of the Flies." He >received the Nobel Prize for Literature. > >I am embarrassed to read the statements above on a Debian mailing >list. It is hate speech, pure and simple—and should be grounds for >expulsion from the project. Please, for everybody's sake, calm the fuck down. This kind of inflammatory rhetoric isn't helping anything. It does not belong here. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: Waiting for the voting vote to finish... :-)
Hey Sam, I hope you're well! On Tue, Nov 23, 2021 at 03:59:16PM +0000, Steve McIntyre wrote: >On Tue, Nov 23, 2021 at 08:49:02AM -0700, Sam Hartman wrote: >>>>>>> "Steve" == Steve McIntyre writes: >> >>Steve> Hey folks, I've got something else to talk about >>Steve> (firmware!!), but I'll wait until this current discussion and >>Steve> vote is finished before I start. Let's not overload people. >> >>would you be willing to let peb and I propose the secret ballots GR? >>We were hoping we were in line behind Russ. > >Sure, no worries. Any progress on that please? -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Re: Waiting for the voting vote to finish... :-)
On Tue, Nov 23, 2021 at 06:43:27PM +0200, Jonathan Carter wrote: >On 2021/11/23 17:59, Steve McIntyre wrote: >> > would you be willing to let peb and I propose the secret ballots GR? >> > We were hoping we were in line behind Russ. >> >> Sure, no worries. > >Ah, I also had one, but can wait my turn. I considered starting a thread in >-project in the meantime, but I'm slightly concerned of information overload >between a large discussion on -project and a running vote. That's exactly my thought here too. >Not to complicate things further, but perhaps some additional co-ordination >of upcoming votes might help (assuming that's even possible)? We could maybe try and do something, but I think it's normally quite rare to be in this situation. (Just remember I'm ahead of you in the queue! :-P) -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Waiting for the voting vote to finish... :-)
On Tue, Nov 23, 2021 at 08:49:02AM -0700, Sam Hartman wrote: >>>>>> "Steve" == Steve McIntyre writes: > >Steve> Hey folks, I've got something else to talk about >Steve> (firmware!!), but I'll wait until this current discussion and >Steve> vote is finished before I start. Let's not overload people. > >would you be willing to let peb and I propose the secret ballots GR? >We were hoping we were in line behind Russ. Sure, no worries. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Waiting for the voting vote to finish... :-)
Hey folks, I've got something else to talk about (firmware!!), but I'll wait until this current discussion and vote is finished before I start. Let's not overload people. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Renaming the FTP Masters
On Thu, Nov 04, 2021 at 03:28:07PM -0700, Felix Lechner wrote: >On Thu, Nov 4, 2021 at 2:14 PM Joerg Jaspert wrote: > >> Debian is a very risk averse and slow to change project. > >We need more trust. The group has to rise—as a moral force, but >gently—over the arbitrary and capricious nature that makes us who we >are. In short, we need more compassion for each other and more >inspiration to do good. Some call it culture. > >The strong maintainer model is one big reason. DAM is desperately >trying to rule. The code of conduct isn't working. We effectively live >under martial law, a very low and unjust way to organize our group's >affairs. What does it mean to be sophisticated? Debian can do better. "Martial law"? Are you *really* trying to claim we're in a setup with "direct military control of normal civil functions" [1]. Stop trying to push buttons, and go and do something useful instead. [1] To quote the same wikipedia article you linked yourself. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Re: Question to the DPL candiates: secret ballots
On Fri, Apr 02, 2021 at 05:01:28PM +0200, Thomas Goirand wrote: >On 4/2/21 4:07 PM, Charles Plessy wrote: >> >> Is that paranoia ? > >Yes it is. If only it was. >I don't think 3 letters agency cares about a Debian statement for RMS, >neither they would care who voted what for our CoC or welcoming everyone >GR, or even who voted for systemd. And you know what? It's also possible >that the vast majority of DDs don't care about these as well... (just >see how many didn't care voting...) > >> This said, I think it is time to vote anonymously. > >I may be a dissonant voice in the current discussion, but at least *I* >do not mind if my vote is disclosed: I take the full responsibilities >attached to my voting, and I'm ok for other DDs to know my opinion. I >would understand if anyone fears harassment after the vote if it is >disclosed, and that would be a good reason, but I do not share the view >that there's a high risk for this to happen. This vote is a lot less >important than many in these threads think. A number of our developers have already been receiving *nasty* threatening mails from morons out there due to involvement in the RMS debate. I won't say which "side" of the RMS discussion those morons were claiming to support (you can probably guess!), but that's not important here. Against such a background, I can certainly understand people being intimidated into choosing not to vote publically. You (and I) may not feel directly affected by such threats, but that does not make them any less real. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. signature.asc Description: PGP signature
Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 12:32:41PM +1100, Dmitry Smirnov wrote: >On Saturday, 3 April 2021 11:19:38 AM AEDT Craig Sanders wrote: >> The witch hunt is not within debian, debian's just being dragged into the >> angry mob. > >Yes to everything you've said, Craig. And the attack on Debian has been >successful so far. So many man-hours were lost on this GR already in >the midst of the pre-release freeze, just to name one problem... Please give up with the hyperbole already. There is no "attack" on Debian here at all. We have a number of Debian developers asking that the project lends its voice to a community-wide call for a safe, non-hostile environment for all. We're about to have a vote on that and some alternative options, following the process that we've all followed for years. Let's wait and see how that turns out. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Re: Willingness to share a position statement?
On Sat, Apr 03, 2021 at 12:26:56PM +1100, Dmitry Smirnov wrote: >On Friday, 2 April 2021 11:09:42 PM AEDT Pierre-Elliott Bécue wrote: >> Thanks for arguing for my point: Communism was a beautiful theoretical >> idea which was implemented by humans and therefore was a miserable >> fuckup in the end. >> >> I still think the concept is really interesting, but I can't see a >> working implementation as soon as there are humans who would want to be >> leaders in such regimes. >> >> I don't see a connection with free speech here, anyway. > >What a nasty disgraceful style of debating you have, Pierre. You might disagree with him, but please stop attacking the person. It's not necessary and only lowers the tone of debate. >You understood very well what I'm saying and I'm is not confirming your >point. Communism is a bad ideology that does not work (and could not work >even in theory) - that's why it should be "cancelled". >Free speech is a beautiful working practice but it is in the way of terrible >ideas and that's why they want to "cancel" free speech. And other people disagree with you on those points. Please accept that and leave it there? -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Re: Cancel "culture" is a threat to Debian
On Thu, Apr 01, 2021 at 07:30:10PM +0300, Sergey B Kirpichev wrote: >On Thu, Apr 01, 2021 at 05:12:55PM +0100, Steve McIntyre wrote: >> *No* attempt has been made to sign that open letter on behalf of the >> project. > >https://lists.debian.org/debian-vote/2021/03/msg00061.html >>8 >I am sure there is a precedent of a position statement being announced >without having a formal vote about it, but I cannot find it at the >moment. >>8--- >By DD, yes. > >Unfortunaly, this wasn't started in the -private@, so the net will >remember. Sigh. You're reading that totally wrong. Gunnar was talking about *precedent* here, i.e. thinking that a public statement might have happened without GR in the past. *NOT* in this particular case. Please listen to what people are telling you. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Re: Cancel "culture" is a threat to Debian
On Thu, Apr 01, 2021 at 06:57:12PM +0300, Sergey B Kirpichev wrote: >On Thu, Apr 01, 2021 at 04:50:15PM +0200, Pierre-Elliott Bécue wrote: >> The first option is one option, the others are different and less >> strong. Having strong options in a GR doesn't turn the whole GR in a >> blackmail > >I would disagree. Especially, given that the first attempt to >"sign on behalf of the Debian" - was without a GR at all. Oh FFS. You are *utterly* wrong here. In discussions with the DPL, several DDs agreed that we did not think he had the constitutional power to "sign" on behalf of Debian, even if he wanted to. That's what caused Steve Langasek to start the GR process in the first place. Following standard Debian practice, various people have proposed amendments and other ballot options for that same GR. *No* attempt has been made to sign that open letter on behalf of the project. Instead, a GR was started to allow DDs to make a decision on this matter. Do you understand that? That's all I'm going to say here. -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Cancel "culture" is a threat to Debian
On Thu, Apr 01, 2021 at 10:40:35AM +0200, Pierre-Elliott Bécue wrote: >Le jeudi 01 avril 2021 à 03:52:23+0300, Sergey B Kirpichev a écrit : >> > Please stop now. >> >> Or?... > >Actually we could ask you to be banned from Debian lists, but here I >assume it was merely a request. Nod, that's exactly what it was. Maybe polite requests aren't effective enough for some people. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: Re: Cancel "culture" is a threat to Debian
On Wed, Mar 31, 2021 at 06:52:49PM +0300, Sergey B Kirpichev wrote: >> I stopped reading after "Thought Criminal" ... >> Honestly, do what you want, but Trumpist > >"I decide who is a jew in the airforce" (c) > >This trans is a wrong trans, isn't? Sergey: I don't know where you're going down this rabbit hole, but I don't think it's helping the discussion at all. Please stop now. -- Steve McIntyre, Cambridge, UK
Re: Willingness to share a position statement?
On Wed, Mar 31, 2021 at 09:12:24AM +1100, Dmitry Smirnov wrote: >On Wednesday, 24 March 2021 11:38:25 PM AEDT Steve McIntyre wrote: >> Freedom of speech does *not* mean freedom from consequences. > >Here is a good reply to this very statement: > >~~~ >"Freedom of speech is supposed to imply freedom from quite a wide range >of possible consequences; mostly consequences like fines or incarceration, >but the spirit of it applies more broadly than that. If I were to say that >[whoever] is free to speak, but I wouldn’t guarantee there would be no >consequences for that speech, wouldn’t it be fair to interpret my words >as a veiled threat? > >The only valid “consequences” for an act of free speech is a solid rebuttal. > >If you think otherwise, then I suggest that you haven’t quite grasped the >point of the concept, or that you simply have tyrannical tendencies >(as many do). >~~~ > >Taken from the following conversation: > > > https://shadowtolight.wordpress.com/2021/02/07/friendly-atheist-defends-censorhip/ Rather than pick on one sentence of what I wrote and quote random people on the internet as a "rebuttal", how about reading and responding to the rest of that mail too? I'm not talking about fines or incarceration, I'm not talking about "threats", I'm talking about the *effects of the speech* itself here. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: Amendment to GR on RMS rejoining FSF
On Sat, Mar 27, 2021 at 12:17:58AM +0530, Sruthi Chandran wrote: > >On 26/03/21 10:45 pm, Sruthi Chandran wrote: > >> >> Dear fellow DDs, >> >> Second the amendment text if acceptable to you :) >> >Re-sending with fixed signature and replacing twitter link with >gnusocial link. > > >> Begin text >> >> Under section 4.1.5 of the constitution, the Developers make the >> following statement: >> >> *Debian’s statement on Richard Stallman rejoining the FSF board* >> >> We at Debian are profoundly disappointed to hear of the re-election of >> Richard Stallman to a leadership position at the Free Software >> Foundation, after a series of serious accusations of misconduct led to >> his resignation as president and board member of the FSF in 2019. >> >> One crucial factor in making our community more inclusive is to >> recognise and reflect when other people are harmed by our >> own actions and consider this feedback in future actions. The way >> Richard Stallman announced his return to the board unfortunately lacks >> any acknowledgement of this kind of thought process. We are deeply >> disappointed that the FSF board elected him a board member again despite >> no discernible steps were taken >> by him to be accountable for, much less make amends for, his past >> actions or those who have been harmed by them. Finally, we are also >> disturbed by the secretive process of his re-election, and how it was >> belately conveyed [0] to FSF’s staff and supporters. >> >> >> We believe this step and how it was communicated sends wrong and hurtful >> message and harms the future of the Free Software movement. The goal of >> the software freedom movement is to empower all people to control >> technology and thereby create a better society for everyone. Free >> Software is meant to serve everyone regardless of their age, ability or >> disability, gender identity, sex, ethnicity, nationality, religion or >> sexual orientation. This requires an inclusive and diverse environment >> that welcomes all contributors equally. Debian realises that we >> ourselves and the Free Software movement still have to work hard to be >> in that place where everyone feels safe and respected to participate in >> it in order to fulfil the movement's mission. >> >> >> That is why, we call for his resignation from all FSF bodies. The FSF >> needs to seriously reflect on this decision as well as their >> decision-making process to prevent similar issues from happening again. >> Therefore, in the current situation we see ourselves unable to >> collaborate both with the FSF and any other organisation in which >> Richard Stallman has a leading position. Instead, we will continue to >> work with groups and individuals who foster diversity and equality in >> the Free Software movement in order to achieve our joint goal of >> empowering all users to control technology. >> >[0] https://status.fsf.org/notice/3796703 >> >> Heavily based on: >> >> [1] https://fsfe.org/news/2021/news-20210324-01.html >> >> [2] >> https://www.eff.org/deeplinks/2021/03/statement-re-election-richard-stallman-fsf-board >> >> End of text Seconded. I may not personally vote this as the #1 option, but it's a good option that I think deserves to be on the ballot. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back signature.asc Description: PGP signature
Re: Willingness to share a position statement?
On Thu, Mar 25, 2021 at 06:28:36PM -0400, Roberto C. Sánchez wrote: >On Thu, Mar 25, 2021 at 10:20:33PM +0000, Steve McIntyre wrote: >> On Fri, Mar 26, 2021 at 12:09:40AM +0200, Adrian Bunk wrote: >> >On Thu, Mar 25, 2021 at 09:38:56PM +0000, Steve McIntyre wrote: >> >>... >> >> We *entirely* have the freedom to discriminate based on >> >> what people say and do around us. We're not a government. We are *not* >> >> in the situation where we *have* to support people saying things that we >> >> believe to be bad, wrong and hurtful. It is *entirely* within our >> >> rights to evaluate people by their words and actions and to decide >> >> whether we wish to talk or work with them in future. >> >>... >> > >> >You are saying companies should always have the right to fire employees >> >if they join an union. >> >> Not at all, please don't twist my words. >> >> Unfortunately, there *are* many places around the world where >> companies can do exactly that. There are many others where rights like >> this are enshrined in other laws. Debian is not an employer here, so I >> don't think your point is relevant? >> >I would hardly call it twisting your words. > >Either private individuals and entities have freedom of association, or >they do not. You can't have it both ways. ACK, true. I'll hold my hand up to that one. My bad. I still don't think this is relevant. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Re: Willingness to share a position statement?
On Fri, Mar 26, 2021 at 12:09:40AM +0200, Adrian Bunk wrote: >On Thu, Mar 25, 2021 at 09:38:56PM +0000, Steve McIntyre wrote: >>... >> We *entirely* have the freedom to discriminate based on >> what people say and do around us. We're not a government. We are *not* >> in the situation where we *have* to support people saying things that we >> believe to be bad, wrong and hurtful. It is *entirely* within our >> rights to evaluate people by their words and actions and to decide >> whether we wish to talk or work with them in future. >>... > >You are saying companies should always have the right to fire employees >if they join an union. Not at all, please don't twist my words. Unfortunately, there *are* many places around the world where companies can do exactly that. There are many others where rights like this are enshrined in other laws. Debian is not an employer here, so I don't think your point is relevant? -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Re: Willingness to share a position statement?
On Thu, Mar 25, 2021 at 09:18:10PM +0100, Gerardo Ballabio wrote: >Steve McIntyre wrote: >> Do we really have to go through this argument *again*? > >I didn't start this discussion. But you've spoken up in a previous discussion and we spoke then. >> Freedom of speech does *not* mean freedom from consequences. > >The point is who decides what the consequences are. >That should be up to the legal system, not to some random group of >people who gather together and decide to enact summary punishment. > >Some types of speech are forbidden by law: hate speech, defamatory >speech, incitement to violate the law (note that debating whether a >law is unjust does NOT equate to inciting people to violate that law). >Everything that isn't forbidden is free speech and nobody must be >discriminated for voicing their opinions. You were wrong the last time you said this kind of thing, and you're still wrong. We *entirely* have the freedom to discriminate based on what people say and do around us. We're not a government. We are *not* in the situation where we *have* to support people saying things that we believe to be bad, wrong and hurtful. It is *entirely* within our rights to evaluate people by their words and actions and to decide whether we wish to talk or work with them in future. Try a simple thought experiment: if you think that only the law (which country?) has any bearing here, is spam filtering allowed? Should we be allowed to block people from our mailing lists or BTS for sending lots of messages saying "Free Software is awful"? ... >> Decrying this as a "political correctness storm" is a favourite >> argument of the morally bankrupt who want the freedom to spout hate >> without being called on it. > >Spouting hate can come from both camps, and the language of this >sentence of yours does seem an example of that, as well as a possible >CoC violation, particularly if you meant to imply that I belong to the >"morally bankrupt". I have no idea about your personal morals. However, claiming that there is a right to free speech without consequences *is* a common tactic of people who wish to say hateful things. Do you dispute that? -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: https://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
On Wed, Mar 24, 2021 at 02:33:19PM -0700, Steve Langasek wrote: >On Wed, Mar 24, 2021 at 10:16:44PM +0100, Nicolas Dandrimont wrote: > >> Seconded. > >> (I'll also second an amended text with s/FSF/FSF board/ or equivalent >> correction) > >I accept an amendment to include the word "board" (which was missed on >accident by me) and would ask the seconders to confirm their acceptance of >this amendment so we can avoid any unnecessary extra variations on the GR >ballot. Seconded on that change -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra signature.asc Description: PGP signature
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
On Wed, Mar 24, 2021 at 01:54:16PM -0700, Steve Langasek wrote: >Under 4.1.5 of the Constitution, the developers by way of GR are the body >who has the power to issue nontechnical statements. > >https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md >is a statement which I believe Debian as a project, and not just individual >Debian developers, should consider signing on to. > >This is a proposal for Debian to sign on to the statement, by adopting the >text from that open letter via GR. Seconded. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen signature.asc Description: PGP signature
Re: Willingness to share a position statement?
Do we really have to go through this argument *again*? On Wed, Mar 24, 2021 at 12:32:31PM +0100, Gerardo Ballabio wrote: >Matthias Klumpp wrote: >> Inclusivity and tolerance does not mean we have to accept every opinion as >> equally valid. > >Equally valid -- no. >Legitimate to express -- yes. > >I am really worried about the increasing trend (not specific to >Debian) towards demanding that people who hold "dissenting" opinions >be removed from their positions, excluded from the public debate, and >even fired from their jobs, which if universally applied would make >them unable to earn a living. That is what dictatorial regimes do -- >often while maintaining a facade of freedom: "Nobody is being >prevented from speaking, we're just making their life miserable >because we don't like what they're saying". That's exactly what's >happening with the current political correctness storm. Say one bad >word and your life might be ruined. Freedom of speech does *not* mean freedom from consequences. If you say unpopular, controversial things then it's entirely reasonable that people around you may evaluate you based on what you've said. They may decide that they don't want to listen to you any more. They may decide that they don't want to work with you any more, or have you in a position of power in a project. Words have power. Decrying this as a "political correctness storm" is a favourite argument of the morally bankrupt who want the freedom to spout hate without being called on it. -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Question to Brian: Why do you need to be DPL to set up foundations?
On Fri, Mar 20, 2020 at 09:41:33AM +0100, Enrico Zini wrote: > >As an example of a voting options that I am considering ad that does not >fit with your proposals above, I would very likely vote for you above >NOTA for a pure DPL election, and I would very likely vote in favour of >a GR option to create a Debian Foundation. I would however rank you >below NOTA if you insisted in conflating the two, as I cannot endorse >what I see as a misuse of our voting system. You would however >incorrectly interpret my vote as a vote against the idea of a Debian >Foundation, underestimating support for something you care about. I hate to just say "me too" on a thread like this, but Enrico has totally captured my thinking here. "Me too". -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Re: Some thoughts about Diversity and the CoC
Hi folks, We feel it is time to respond to this thread in our capacity as the Community Team, and take a moment to remind everyone of some details in the Code of Conduct.[1] Notably, we'd like to bring your attention to the first point: ***Be respectful***. Please be respectful of others when communicating within Debian - mailing lists, IRC, the BTS, *everywhere*. Name calling and direct or indirect insults are not appropriate. We explicitly recognize that being respectful includes being respectful of people's identities. "A community in which people feel threatened is not a healthy community," and expressing some opinions (including those that are biphoobic, homophobic, misogynistic, racist, or transphobic) creates a space where people feel threatened and is not appropriate for the Debian Community. We would also like to remind you that "what you write once will be read by hundreds of persons." Journalists cover what happens in the Debian Project and on Debian mailing lists. Even when you think you're just communicating within the community, you are still representing the community. Much of that communication is public. Many of us have friends (or partners) within the Debian community and there are those for whom it has become a significant social space in our lives. Nonetheless, the Debian Project should also be considered a professional environment. When in doubt, ask yourself: Would I say this to a coworker or colleague? If you're ever unsure about how you're expressing something or whether something crosses a line, or to be reassured that you are a valuable, welcome member of the community, please drop us a line at commun...@debian.org and we'll do what we can to assist. [1]: https://www.debian.org/code_of_conduct Thanks and cheers, Molly and Steve, for the Community Team -- Steve McIntyre 93...@debian.org Debian Community Team commun...@debian.org signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2019: Call for nominations
On Sun, Mar 10, 2019 at 11:20:03AM +0100, Daniel wrote: > > >On 10/03/2019 04:44, Steve Langasek wrote: > >> >> This is an obviously untrue signature. > >Why do you want to taint the elections with more bullying, insulting and >disrespectful comments? He's telling the truth, nothing more. Daniel, I don't know what you think you're trying to achieve here, but nothing positive is happening. Please stop. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Re: DPL Voting period
On Sun, Apr 09, 2017 at 11:35:06AM +0200, Stefano Zacchiroli wrote: >On Sat, Apr 08, 2017 at 07:34:34PM +0200, Kurt Roeckx wrote: >> We're currently in the voting period, the discussion/campaigning >> period is over. Can I please ask everybody to stop talking about >> things related to the DPL election on this list. > >I'm not sure I understand why. Since when it is _forbidden_ to discuss >outside the campaign period? I don't know about *forbidden*, but it's been a long-standing tradition to have a break from discussion once people start voting... -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Questions for Mehdi: roadmap?
Hi Mehdi, First of all, thanks for standing again! Do you have any specific things that you'd like to see on a Debian roadmap yourself? Assuming that roadmap ideas are forthcoming, how do we ensure that teams responsible for the various areas have the will and effort to follow through? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Question for Chris: organising more meetings?
Hi Chris, First of all, thanks for standing! I think we've been trying to encourage people to organise more sprints and mini-debconfs and other face-to-face meetings over the last few years, but I'm worried that we're not getting very much traction. what would you do to improve the situation here? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
On Fri, Jul 08, 2016 at 03:27:56PM +0200, Margarita Manterola wrote: > >I'm therefore proposing the following General Resolution: > >=== BEGIN GR TEXT === > >Title: Replace "Chairman" with "Chair" throughout the Debian Constitution > >All appearances of the word Chairman shall be replaced with the word Chair. > >=== END GR TEXT === Seconded. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers" signature.asc Description: Digital signature
Re: Proposed GR: Acknowledge that the debian-private list will remain private
On Thu, Jul 07, 2016 at 03:37:08PM +0200, Nicolas Dandrimont wrote: >In 2005, the body of Debian Developers passed a General Resolution[1] requiring >the creation of a declassification team for the debian-private mailing list. >For the past ten years, the implementation of this GR has never materialized, >despite an explicit call for volunteers[2] by the DPL in 2010. > >[1] https://www.debian.org/vote/2005/vote_002 >[2] https://lists.debian.org/debian-project/2010/05/msg00105.html > >Over the years, several important discussions have happened on the >debian-private mailing list that needed to stay private. Oftentimes, when a >discussion has carried on for a while, some participants have reminded others >that the discussion should be summarized in a public thread on either the >debian-devel or the debian-project mailing lists. > >While we agree with the intentions behind the original GR, we believe it is now >time to acknowledge that the declassification of debian-private will never >happen, and that we should instead strongly encourage developers to move >discussions to public channels as soon as the sensitivity of the discussion >subsides. > >We therefore propose the following General Resolution: > >=== BEGIN GR TEXT === > >Title: Acknowledge that the debian-private list will remain private. > >1. The 2005 General Resolution titled "Declassification of debian-private > list archives" is repealed. >2. In keeping with paragraph 3 of the Debian Social Contract, Debian > Developers are strongly encouraged to use the debian-private mailing > list only for discussions that should not be disclosed. > >=== END GR TEXT === > >Thanks for your consideration, Yay, seconded. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I... signature.asc Description: Digital signature
Re: draft alternative proposal: fix problem at the root
On Wed, Dec 03, 2014 at 02:46:25PM +0100, Josselin Mouette wrote: >Clint Adams wrote: >On Tue, Dec 02, 2014 at 10:50:30PM -0500, Michael Gilbert wrote: >> Disbanding the TC would likely do more harm than good. There would > be >> no way to conclude a disagreement. > >I believe that there is evidence prior to 1999 that neither of >these sentences is accurate. > >There is also evidence of maintainers not giving a f*** about making >their packages integrate correctly with the rest of the distribution, or >being incapable of collaborating with other developers. > >We need an arbitration body. But we need one that works, not a club >where only veteran unix admins feel at home. We definitely need a group which represents Debian more closely. Hopefully the term limit idea will help promote that. I'd love to see people involved with backgrounds in the desktop teams, for example. Joss, have you considered nominating yourself? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I... -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203143239.gt16...@einval.com
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
On Mon, Dec 01, 2014 at 12:20:25PM +0100, Stefano Zacchiroli wrote: > >=== >The Constitution is amended as follows: > >--- >--- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100 >+++ constitution.2-S.txt 2014-11-21 16:56:47.328071287 +0100 >@@ -299,8 +299,20 @@ >Project Leader may appoint new member(s) until the number of >members reaches 6, at intervals of at least one week per >appointment. >-5. If the Technical Committee and the Project Leader agree they may >+5. A Developer is not eligible to be (re)appointed to the Technical >+ Committee if they have been a member within the previous 12 months. >+6. If the Technical Committee and the Project Leader agree they may >remove or replace an existing member of the Technical Committee. >+7. Term limit: >+ 1. On January 1st of each year the term of any Committee member >+who has served more than 42 months (3.5 years) and who is one >+of the two most senior members is set to expire on December >+31st of that year. >+ 2. A member of the Technical Committee is said to be more senior >+than another if they were appointed earlier, or were appointed >+at the same time and have been a member of the Debian Project >+longer. In the event that a member has been appointed more >+than once, only the most recent appointment is relevant. > > 6.3. Procedure > >--- > >As a transitional measure, if this GR is passed after January 1st, 2015, >then the provision of section §6.2.7.1 is taken to have occurred on January >1st, 2015. >=== Seconded. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. signature.asc Description: Digital signature
Re: All DPL candidates: DPL Term lengths and limits?
On Fri, Mar 28, 2014 at 01:56:50PM +, Lars Wirzenius wrote: >On Fri, Mar 28, 2014 at 01:24:13PM +0000, Steve McIntyre wrote: >> On Fri, Mar 28, 2014 at 10:06:00AM +0100, Lucas Nussbaum wrote: >> >The 2-week voting period made sense when the Constitution was written, >> >as intermittent internet access was much more likely back then. But >> >today, it's probably less justified. >> >> Do you want to disenfranchise DDs who are on vacation? > >Even if we keep the two-week voting period, there'll be people who >can't vote because they're away exactly those two weeks, even if it's >fewer of them. Knowing the voting dates beforehand would help with >planning. ACK. >That said, I am in favour of keeping the existing voting period. All >the energetic parts of the DPL election process mostly cease by the >time the discussion period ends, so a longer voting period doesn't >cause us to spend more effort on the DPL election. The only benefit >from shortening the voting period would be to reduce load on >www.debian.org from people who keep refreshing the results page to see >if the results are known yet. Thanks - that matches my own thinking, but better articulated. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328152019.gb25...@einval.com
Re: All DPL candidates: DPL Term lengths and limits?
On Fri, Mar 28, 2014 at 10:06:00AM +0100, Lucas Nussbaum wrote: > >What we could try to do, though, is to make the yearly election process >more efficient. Currently, it spans over 6 weeks, with one week for >nominations, 3 for compaigning, and 2 for voting. We could reduce that >to 3/4 weeks, with: >- election-3 weeks: deadline for nomination (without an explicit start of > nomination period, other than a mail from the secretary announcing the > general planning of the election) >- from election-3w to election-1w: campaign >- then, one week for voting. > >The 3-week campaign period is longer than our default discussion period >for GRs (2 weeks). I don't think that there's much to gain by having an >additional week here. > >The 2-week voting period made sense when the Constitution was written, >as intermittent internet access was much more likely back then. But >today, it's probably less justified. Do you want to disenfranchise DDs who are on vacation? -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there? -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140328132413.ga25...@einval.com
Re: non-free?
On Tue, Mar 25, 2014 at 09:32:26AM +0100, Frank Lin PIAT wrote: >On Tue, 2014-03-25 at 15:29 +0900, Stefano Zacchiroli wrote: >> Because as long as we document it, it's very hard to claim that >> "non-free" is not part of Debian, when you could just add it as a >> keyword side-by-side with "main" in your sources.list. > >The firmware have been moved from main to non-free a few years ago. The >unintended consequences is that almost every system now use the non-free >suite. >Therefore users are more likely to install non-free packages. Yup. Various conversations have happened around firmware in the last few years, but this is an effect that some people may not be aware of. So... Neil and Lucas: what do you have to say on this front? Of all the things that *could* be done here, what would you like to see personally? -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140325102502.gi9...@einval.com
Re: Both DPL candidates: appropriate choice of dresswear for the DPL
On Fri, Mar 21, 2014 at 01:27:11PM +, Lars Wirzenius wrote: >On Fri, Mar 21, 2014 at 01:44:54PM +0100, Wouter Verhelst wrote: >> However, Debian is not a cult. > >Indeed not. We are a clan. Which inspires my next question. > >Neil and Lucas: do you have, or will you get, a Debian kilt and wear >that for Deconf14? I know that Neil has a kilt already and is not afraid to use it: http://wedding.einval.com/gallery/day_raw/abj -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers" -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140321133752.ga12...@einval.com
Re: GR proposal: code of conduct
On Tue, Feb 25, 2014 at 01:47:07AM -0600, Ean Schuessler wrote: >- "Steve McIntyre" wrote: > >> I'm not sure how wiki.d.o bans would fit. We *could* list banned >> users >> on a specific page, I guess. But the vast majority of the bans we >> ever >> enact are for spamming. > >I feel like spamming and trolling should be considered a different >phenomena than bans brought for other reasons. Agreed, 100%. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225222948.gy9...@einval.com
Re: GR proposal: code of conduct
On Mon, Feb 24, 2014 at 09:48:38AM +0100, Thijs Kinkhorst wrote: >On Mon, February 24, 2014 08:47, Alexander Wirt wrote: >> - "The administrators will divulge any bans to all Debian Developers for >> review". I know that this is the case for lists.d.o now, but I never saw >> other anything from other services. Are _all_ other administrators of >> 'Debian communication forums' aware of that change? If we go that way, >> we should probably move away from announcing them on -private and move >> to something else. Like an mbox on master, or something else (and in my >> eyes - non-public). > >It may make sense to publish bans in-band in the medium where they apply >as much as possible. ML bans are sent to a mailinglist, IRC bans can be >viewed already via the IRC protocol; probably it would also make sense if >bans on the web forum would also somehow be registered in the context of >that forum. I'm not sure how wiki.d.o bans would fit. We *could* list banned users on a specific page, I guess. But the vast majority of the bans we ever enact are for spamming. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140225042403.gu9...@einval.com
[all candidates] Removing or limiting DD rights?
Hi guys, First of all, thanks to all three of you standing in the DPL election this year. I know it's a daunting task! :-) I've already seen some debate about how we could/should attract more contributors, which is a perennial question in Debian. I personally don't think we're ever likely to "solve" that issue permanently, but it's clearly something that's always going to be very important for us. I have a related question, but more on the opposite end of the spectrum I suppose: Are we strict enough with our existing contributors? When we're trying to work together as best we can to make the Universal Operating System happen, what could/should we do with contributors who hinder our work? Sometimes that hindrance is inadvertent, sometimes it seems deliberate. At other times it looks like we have developers who are just not paying attention to what they're doing or who just don't care about the goals of the project. Occasionally we see direct action to censure or even expel DDs, but these are only ever in the most blatant of cases. By the time that happens, large amounts of damage may be done to the project: delayed releases, lost users, loss of motivation for other contributors. I'm wondering: is this something that you think is a real problem, and if so what do you think we could do about it? -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130325162223.ga11...@einval.com
Re: [Call for seconds] GR: diversity statement for the Debian Project
On Mon, May 07, 2012 at 08:32:41PM +0200, Francesca Ciceri wrote: > >TEXT TO BE VOTED STARTS HERE > >The Debian Project welcomes and encourages participation by everyone. > >No matter how you identify yourself or how others perceive you: we >welcome you. We welcome contributions from everyone as long as they >interact constructively with our community. > >While much of the work for our project is technical in nature, we value >and encourage contributions from those with expertise in other areas, >and welcome them into our community. > >TEXT TO BE VOTED ENDS HERE Seconded. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. signature.asc Description: Digital signature
Re: Comments on the constitution?
On Tue, Aug 30, 2011 at 11:29:07AM -0500, Gunnar Wolf wrote: >Stefano Zacchiroli dijo [Mon, Aug 29, 2011 at 10:17:22AM +0200]: >> (…) >> The main question is: how would people feel about a DPL standing for >> election for a 2 year period, provided that there is an "easy" way to >> call for a mid-term election after 1 year? "Easy" should be defined in a >> way that it is not socially awkward and allow any of the two parts (the >> DPL or the DD body) to call for an election that by default won't >> happen. >> >> At present, I don't have any bright idea on how to implement the "not >> socially awkward" part preserving full transparency. A possibility might >> be to allow a given number of DDs to request in private a mid-term >> election to the secretary. But that clearly trades-off transparency for >> social un-awkward-ness. IMHO it would match the spirit of the current >> Constitution provision that DPL votes are secret, but YMMV. It would >> also possibly increase the level of trust we put in the Secretary. > >Humm… An idea could be: > >‣ The term is defined to be for one year, with the possibility of one > automatic renewal >‣ If by (election date + 10 months) the DPL sends a (signed, > validated, blah) message, a simple referendum is held: secret vote > between a "yes" and a "no" (and... Further discussion? :-} ) > ‣ If the DPL seeking renewal gets a majority, his term is prolonged to >a second year > ‣ If the DPL does not get a majority, he can still participate in a >regular election >‣ This mechanism can only be used once — A DPL wanting to run a third > term must win a regular (full) election /me shudders at the extra complexity, especially how it would be worded in the constitution. I'm tempted to say: let's just leave things the way they are. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110830191619.ge3...@einval.com
Re: Question for Stefano: Length of the DPL term
On Sat, Mar 19, 2011 at 03:20:59PM +0100, Stefano Zacchiroli wrote: >On Fri, Mar 18, 2011 at 05:36:37PM +0100, Martin Zobel-Helas wrote: >> in your platform you wrote that you experienced that serving as DPL is >> a task with a rather long bootstrap time. You didn't wrote how long >> this exactly was, but i guess something about 2-3 month. > >I'd say that is a reasonable figure, yes. > >> Now my question: What do you think about changing the constitution to >> extend the length of the DPL term to, lets say, two years? > >I thought about this quite a bit in the past months. I've found it to be >a surprisingly complex problem. > >I agree that a longer term will improve the status quo with respect to >the "bootstrap time" issue. I've even thought about proposing the >corresponding constitutional change, but in the end I've decided that >it's not something I want to propose myself while still being DPL, for >obvious reasons. > >I was pondering to propose it just after having stepped down, but I see >various contraindications that need to be addressed first: > >- There are risks in lengthening the term, for instance the consequences > of a DPL going MIA / burning out shortly after the terms begin get > worse. I'm aware that a GR can fix that, but it's a rather difficult > step to take at a social level, especially considering that the DPL > themselves can fail to realize they're on (the verge of) burn out. > >- Being DPL it's a volunteer job and it's one where you might feel quite > some responsibility. A longer term will increase the "scare away" > factor, possibly reducing the number of DPL candidates. Agreed. I'll be honest (in public) for the first time - about halfway through my second DPL term, I felt very demotivated and burnt-out, almost to the point of resigning early to trigger an election. For a variety of reasons (and after a lot of soul-searching) I decided to stick with things. A year is *both* a long term and a short term in this context. There's a lot of startup time and there's never enough time to do what you want to achieve (of course), but it's also a lot of time to promise to the project in one lump. Making it longer might just make it worse. >All in all, I believe we need a solution in which the *default* term >period is longer than now (say, 2 years), but in which there is an easy >way out at midterm for both the project (in case people are not happy >about the DPL) and the incumbent DPL (in case they can no longer offer a >good service to the project and would like to quit without fearing >shame). > >Something that might work is that at midterm the DPL has to explicitly >state whether they are willing to continue for another midterm or >not. If the DPL decides to continue, the project can request elections >to the secretary anyhow, provided that a given number of Developers >(defined in terms of Q) want so. The developers who want election should >probably be allowed to do so anonymously, for coherency with the fact >that DPL elections are anonymous already. > >The last paragraph is just a braindump, to which I haven't given much >thought, but since you asked ... :-) It's a topic that stands further thought from more people, I guess... -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110321164607.ga12...@einval.com
Re: Debian Project Leader Elections 2011: Call for nominations
On Fri, Mar 11, 2011 at 11:16:41AM +0100, Amaya wrote: >Joachim Breitner wrote: >> A mudslinging party is not something to aim for. But if it turns out >> that there are differing views on important project-wide issues within >> Debian, and there are candidates for each side of some discussion, >> then having an intense debate over these issue within the rituals of >> the campaigning, summarized by platforms and rebuttals, for those not >> following d-vote, and ended by a project-wide election seems to be >> better than some endless discussions between few people on d-devel or >> d-project. > >You are missing the point. Nobody is against a heated debate about our >goals and issues. > >> But this year, of course, it would already be nice if we would not >> make zack talk to himself during campaigning :-) > >Personally I am thrilled to see, at last and for once, the whole project >agree on something. This must mean zack is a truly exceptional person. Nah, he smells. Oh, wait, we're *not* mud-slinging! :-P -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011031011.ga23...@einval.com
Re: Debian Project Leader Elections 2011: Call for nominations
On Tue, Mar 08, 2011 at 07:20:17PM +0100, Stefano Zacchiroli wrote: >On Tue, Mar 08, 2011 at 12:09:16PM -0600, Gunnar Wolf wrote: >> I think that is very likely to make the other nominations and >> discussion close to a NOOP. Of course, I'm not discouraging any other >> DD to nominate him/herself and compete to win > >I believe that a DPL election with a single candidate, no matter whom, >would be unfortunate. > >Campaigning periods are some of those few moments when people sit down >and discuss publicly project vision, goals, "politics", etc. A campaign >with a single candidate will diminish the attractiveness of posing >questions to the sole candidate and, as a consequence, the interest of >the debate. More generally, recent elections seem to show that the more >the candidates, the more interesting and useful the debate. > >... furthermore, I'm not ready to give up so easily the possibility of >increasing my free time starting from April 18th :-) *grin* No escape! -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110309111232.gb6...@einval.com
Re: Naming of non-uploading DDs (Was: GR: welcome non-packaging contributors as Debian project members)
On Wed, Sep 15, 2010 at 09:26:59AM +0200, Lucas Nussbaum wrote: > >If we go for DDs without upload rights, I think that we should be >extremely careful about not transforming this new kind of DDs into second-class >members of the project. A way to do that is to avoid giving them a name, >and emphasize the fact that they are DDs, not another sub-kind of >project members. The "no upload rights" part would just be a minor >technical distinction. > >Another way to put it is, imagine you are a DC, and are writing your CV. >What should you write about your status in Debian? "Debian Contributor"? >"Debian Developer"? If we create the "Debian Contributor" term, then I'm >sure that for many DCs, it will be difficult to write "Debian Developer" >there (Imposter Syndrome, etc), even if that's what should really be >written, since their contributions to Debian are not less important than >those of other DDs. > >Just leaving it up to DAM to choose a term would not be enough to avoid >that. IMHO, DDs without upload rights should not have any sexy name, and >the distinction between them and DDs with upload rights should only be >made where it's necessary. Definitely. -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone signature.asc Description: Digital signature
Re: Question to all Candidates: we want more, aren't we?
On Fri, Apr 02, 2010 at 01:34:02AM +0900, Charles Plessy wrote: >Le Thu, Apr 01, 2010 at 09:57:38AM +0200, Frank Lin PIAT a écrit : >> >> Debian project raise it's expectation every year: higher quality, more >> package, more architectures, more Desktops, etc... (cool). >> >> How do we face the challenge to do more every year? >> What would you do about it, as a DPL? > >Hi Frank, > >I think that we should open Debian's door wider, and reduce restrictions on the >operations on our infrastructures, so that the growth is sustainable. Meaning what, precisely? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I... -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100401165913.gb7...@einval.com
Re: Question to all (other) candidates
On Wed, Mar 24, 2010 at 09:57:16AM +0100, Stefano Zacchiroli wrote: >On Tue, Mar 23, 2010 at 06:49:51PM +0100, Wouter Verhelst wrote: >> So, since part of the reason that I joined the race was to make sure it >> wouldn't get too boring, I was hoping there'd be a bit more life on this >> list. Since there isn't, allow me to ask a few questions myself. > >FWIW, I disagree with that or, better, I think "too boring" is a >subjective notion. I've been indexing DPL campaigning questions this and >last year, and we're currently at about 20 discussion topics, with 1 >more week of campaigning ahead of us. Last year campaigning has been >*way* more quiet :-) Sure, but to a certain extent that depends on the number of candidates. If you look back a few more years, you'll see much more. >There are various issue which I presume block sending frequently, >according to a given period, "bits from the DPL" mail to the project. > >I believe a significant one among such issues is the "expectation" that >the DPL knows DDs have on the monthly bits, and therefore the perceived >weight of of preparing those bits. My guess is that, on these premises, >actually sending out the DPL bits mail is a time consuming and >potentially stressing matter. I believe that, by diluting it with the >feed idea, it will become way more bearable. I hope so, yes. :-) For me, the "bits" emails take a long time to prepare. And the longer you leave between doing them, the bigger and more intimidating they become. It's a vicious cycle. :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Dasmohapatra -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100324111214.ga24...@einval.com
Re: Bits from the release team and request for discussion
On Tue, Aug 11, 2009 at 01:07:33PM +1000, Anthony Towns wrote: > >Any thoughts? We could have such a vote over and done in about two weeks, >with the DPL's consent, and it'd seem a lot more inclusive and less >cabal-tastic than how things seem to be working atm... Personally, I think the last thing we need is a GR on this front right now. There's still discussion going on and plenty of scope for interested people to make their feelings known. We don't need the overhead of a GR at all that I can see. -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering" -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
