Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Fri, Apr 05, 2024 at 12:26:03PM +0200, Andreas Tille wrote: > > also: (NMU-)uploads to DELAYED/15 are great. > Sorry, I do not feel my time well spent on just curing a symptom > (unfixed RC bug) via NMU instead of addressing the underlying cause > that the package is maintained by a single person. so you value your values and needs higher than our shared and agreed values. noted. (also, pressuring people to accept more co-maintainers can have serious side effects as became very visible last weekend with xz upstream...) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make facts great again. signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote: > [...] I could follow the normal NMU procedure but I do not consider > this a sustainable solution. [...] > I did not uploaded my work but I would like to know what action is > considered acceptable by the voters. I repeat that the package is no > key package for which I would not consider what I did above. Please > simply fill in the form: > >[ ] Its not acceptable, don't do that >[ ] We should discuss this on debian-devel, possibly do some GR >before things like this are permitted >[ ] Wait one week before uploading >[ ] Wait one day before uploading >[ ] Just upload provided you care for any break your action might >have caused. >[ ] ??? > > What do you think? rereading this, I must say I think "wtf". please *do* follow the NMU procedures or salvage the package. (or leave it alone.) also: (NMU-)uploads to DELAYED/15 are great. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Everyone is entitled to their own opinion, but not their own facts. signature.asc Description: PGP signature
Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)
On Thu, Apr 04, 2024 at 02:59:34PM +0200, Andreas Tille wrote: > I would like to learn what options I have to realise paragraph >Packaging standards > of my platform. I also think this feels a bit like abusing the election audience for a topic which should be discussed on -devel outside campaigning. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The greatest danger in times of turbulence is not the turbulence; it is to act with yesterdays logic. (Peter Drucker) signature.asc Description: PGP signature
Re: call for seconds - separate proposal text for 2023/vote_002
On Wed, Nov 22, 2023 at 07:16:48PM +0100, Bart Martens wrote: > Hello, I hereby welcome seconds for adding this text to 2023/vote_002 > as a separate proposal. > > START OF PROPOSAL TEXT > > Debian Public Statement about the EU Cyber Resilience Act (CRA) and the > Product Liability Directive (PLD) > > The CRA includes requirements for manufacturers of software, followed > up by the PLD with compulsory liability for software. The Debian > project has concerns on the impact on Free and Open-Source Software > (FOSS). > > The CRA makes the use of FOSS in commercial context more difficult. > This goes against the philosophy of the Debian project. The Debian Free > Software Guidelines (DFSG) include "6. No Discrimination Against Fields > of Endeavor - The license must not restrict anyone from making use of > the program in a specific field of endeavor." A significant part of the > success of FOSS is its use in commercial context. It should remain > possible for anyone to produce, publish and use FOSS, without making it > harder for commercial entities or for any group of FOSS users. > > The compulsory liability as meant in the PLD overrules the usual > liability disclaimers in FOSS licenses. This makes sharing FOSS with > the public more legally risky. The compulsory liability makes sense for > closed-source software, where the users fully depend on the > manufacturers. With FOSS the users have the option of helping > themselves with the source code, and/or hiring any consultant on the > market. The usual liability disclaimers in FOSS licenses should remain > valid without the risk of being overruled by the PLD. > > The Debian project asks the EU to not draw a line between commercial > and non-commercial use of FOSS. Such line should instead be between > closed-source software and FOSS. FOSS should be entirely exempt from > the CRA and the PLD. > > END OF PROPOSAL TEXT seconded, thank you. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The upcoming clima apocalypse is the big elephant in every room now. signature.asc Description: PGP signature
Re: Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Sun, Nov 19, 2023 at 11:21:47PM +, Luca Boccassi wrote: > Second version, taking into account feedback. Looking for seconds at > this point: > > - GENERAL RESOLUTION STARTS - > > Debian Public Statement about the EU Cyber Resilience Act and the > Product Liability Directive > > The European Union is currently preparing a regulation "on horizontal > cybersecurity requirements for products with digital elements" known as > the Cyber Resilience Act (CRA). It's currently in the final "trilogue" > phase of the legislative process. The act includes a set of essential > cybersecurity and vulnerability handling requirements for manufacturers. > It will require products to be accompanied by information and > instructions to the user. Manufacturers will need to perform risk > assessments and produce technical documentation and for critical > components, have third-party audits conducted. Security issues under > active exploitation will have to be reported to European authorities > within 24 hours (1). The CRA will be followed up by an update to the > existing Product Liability Directive (PLD) which, among other things, > will introduce the requirement for products on the market using software > to be able to receive updates to address security vulnerabilities. > > Given the current state of the electronics and computing devices market, > constellated with too many irresponsible vendors not taking taking > enough precautions to ensure and maintain the security of their products, > resulting in grave issues such as the plague of ransomware (that, among > other things, has often caused public services to be severely hampered or > shut down entirely, across the European Union and beyond, to the > detriment of its citizens), the Debian project welcomes this initiative > and supports its spirit and intent. > > The Debian project believes Free and Open Source Software Projects to be > very well positioned to respond to modern challenges around security and > accountability that these regulations aim to improve for products > commercialized on the Single Market. Debian is well known for its > security track record through practices of responsible disclosure and > coordination with upstream developers and other Free and Open Source > Software projects. The project aims to live up to the commitment made in > the Debian Social Contract: "We will not hide problems." (2) > > The Debian project welcomes the attempt of the legislators to ensure > that the development of Free and Open Source Software is not negatively > affected by these regulations, as clearly expressed by the European > Commission in response to stakeholders' requests (1) and as stated in > Recital 10 of the preamble to the CRA: > > 'In order not to hamper innovation or research, free and open-source > software developed or supplied outside the course of a commercial > activity should not be covered by this Regulation.' > > The Debian project however notes that not enough emphasis has been > employed in all parts of these regulations to clearly exonerate Free > and Open Source Software developers and maintainers from being subject > to the same liabilities as commercial vendors, which has caused > uncertainty and worry among such stakeholders. > > Therefore, the Debian project asks the legislators to enhance the > text of these regulations to clarify beyond any reasonable doubt that > Free and Open Source Software developers and contributors are not going > to be treated as commercial vendors in the exercise of their duties when > merely developing and publishing Free and Open Source Software, with > special emphasis on clarifying grey areas, such as donations, > contributions from commercial companies and developing Free and Open > Source Software that may be later commercialised by a commercial vendor. > It is fundamental for the interests of the European Union itself that > Free and Open Source Software development can continue to thrive and > produce high quality software components, applications and operating > systems, and this can only happen if Free and Open Source Software > developers and contributors can continue to work on these projects as > they have been doing before these new regulations, especially but not > exclusively in the context of nonprofit organizations, without being > encumbered by legal requirements that are only appropriate for > commercial companies and enterprises. > > == > > Sources: > > (1) CRA proposals and links: > > https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation > PLD
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, Nov 13, 2023 at 02:19:38PM +0100, Aigars Mahinovs wrote: > Correct. And I agree with that effect: same here. > The *one* negative impact I can see of this legislation is impact on small > integrators that were used to being able to go to a > client company, install a bunch of Ubuntu Desktop workstations, set up a > Ubuntu Server for SMB and also to serve the website > of the company, take one-time fee for their work and be gone. Now it would > have to be made clear - who will be maintaining those > machines over time, ensuring they are patched with security updates in > time, upgraded to new OS releases when old ones are no > longer supported and so on. I don't see this a negative impact because this will in the long term hopefully prevent the effect which is similar to a small freelancer setting up a kitchen machine which will blow up after some time. And noone wants that, whether it's been a small or big company responsible for the exploding kitchen. And people buying kitchen machines have understood they want safe machinery in kitchens... computers need maintenance, else they will "explode" or be exploited. [...] > Lots of interesting questions. But at no point does any responsibility get > automatically assigned to, for example, Debian or individual > open source developers. yup. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If we'd ban all cars from cities tomorrow, next week we will wonder why we waited for so long. signature.asc Description: PGP signature
Re: On community and conflicts
On Thu, Mar 16, 2023 at 07:53:22AM -0400, Roberto C. Sánchez wrote: > Can we have a clear statement of what "directly affects people"? for those having lost people due to covid, hearing someone say it's a hoax, is definitly painful. and this affects Debian directly: so far we know about one dead DM (yes, Debian Maintainer) and personally I know several suffering from long covid. surprise: you're not invisble when you close your eyes. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ War is peace. Freedom is slavery. Covid is like the flu. 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: > 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. I think we might even want to link to it from the official > page, inverting the way we currently do it. I agree. "It just needs someone who does the work." (tm) And if noone is volunteering, maybe we dont need/want it for real, after all. Time will tell. Talk is pointless here, IMO. It just needs someone who does the work, first. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ We are done with ‘world leaders’. Countries are on fire. Cities are drowning. People are dying. This is what scientists and activists have been warning the world and politicians about. It’s here. We ARE facing the impacts of the climate crisis. Forget about the future, it’s now. fridays for future - https://nitter.net/fff_digital/status/1304520941012242432 signature.asc Description: PGP signature
Re: Voting period
resending publically, cause Kurt so very much deserves it! thank you, Kurt! On Sat, Sep 17, 2022 at 01:17:24AM +0200, Kurt Roeckx wrote: > I did not have time to put the last option on the website, but it has > enough seconds. thanks! (:*) if there are specific problems, you should spell them out. *more hugs*, Kurt! (!!) seriously. else: enjoy, Debian can wait. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It's not about saving the climate or the planet, it's about saving us, the children and grandchildren. The planet will survive anyway. signature.asc Description: PGP signature
new proposal: free and and non-free installers with SC change
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".) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The wrong Amazon is burning. signature.asc Description: PGP signature
Re: Status of proposal E (SC change + non-free-firmware in installer)
Hi Russ, thank you for working on option E! :) that said, I think I want option F, where F is to E what B is to A, (according how I read https://www.debian.org/vote/2022/vote_003 now) or IOW, option E where both types of installers (with and without non-free firmwarez) are offered. (so a new option F.) I'd appreciate if someone would word this more formally so this can be seconded and become an option on the ballot. or maybe, it's possible to reword option E, because my only problem is with the last sentence which reads "We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages." and which I'd rather like to read "We will publish these images as official Debian media, in addition to the current media sets that do not include non-free firmware packages." (so s#replacing#in addition to# which I'm not sure is worth another option on the ballot. maybe it is.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The system isn't broken. It was built this way. signature.asc Description: PGP signature
Re: Possible draft non-free firmware option with SC change
On Fri, Sep 09, 2022 at 12:46:05PM +0200, Simon Josefsson wrote: > No, not like now. Today we and our users can chose to download non-free > content if they want. Some do. Some don't. With Steve's proposal, as > I understand it, that choice will be taken away. good thing that we have 5 proposals right now on https://www.debian.org/vote/2022/vote_003 and not just one. :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Bottled water companies don't produce water, they produce plastic bottles. 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: > 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. > > = seconded, thank you! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If you liked Corona, you will also enjoy the upcoming global climate disaster. 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: > 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. seconded. I'll also second the revised version of this. (I just have refrained from doing so as its not clear to me yet whether a 'final' one has emerged.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "It' easier to fool people than to convince them they have been fooled." (Mark Twain) signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Thu, Sep 01, 2022 at 06:02:38PM +0200, Simon Richter wrote: > A large part of installations now run inside virtual machines and have no > use for device firmware. yes. > Having a free-software-only installer is an easy > way for image builders to ensure that anything they build will be > redistributable. no. if you build images, you don't use d-i but fai, debuerreotype, mmedebstrap debootstrap or your-custom-script-being-used-since-1997 or something else, but hardly anyone uses d-i for this use-case. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ https://showyourstripes.info signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Wed, Aug 24, 2022 at 10:12:48AM +0200, Bart Martens 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. > > = seconded, thanks, Bart. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make earth cool again. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
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"? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ There are no jobs on a dead planet. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote: > As far as I can tell, both Steve's and Gunnar's proposal would make > Debian less of a free software operating system than it is today. That > makes me sad. My preference for an outcome would be along the following > lines. > > == > > 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. > > Therefor we will not include any non-free software in Debian, nor in the > main archive or installer/live/cloud or other official images, and will > not enable anything from non-free or contrib by default. > > 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. as pollo said: I disagree with you, but I understand the rationale. I think having such an option on the ballot makes sense. Seconded. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Every time you see the word "smart" used to describe a device, replace it with "surveillance." Surveillance watch. Surveillance streetlights. Surveillance oven. Surveillance toilet. Surveillance car. Surveillance city. (@mollyali) signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
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, thanks Gunnar. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make earth cool again. signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
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. 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 & thanks for working on this, Steve & everybody else! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Where will your kids go when they become climate refugees? signature.asc Description: PGP signature
Re: General Resolution: Liquidate donated assets as soon as possible
On Sun, Jun 19, 2022 at 11:32:40AM -0400, Louis-Philippe Véronneau wrote: > We had a nice discussion on debian-private (the thread is named > "Volatile assets, Debian money and SPI"), so I didn't feel I needed to > have a long text explaining the rationale. sigh. sad to see what happened to "Debian works in the open". > For those not on that list, the TL;DR would be: a kind donor gave Debian > stock (SPDR S 500 trust ETFs) and SPI has been holding on to it since > then. i'm not sure summarizing threads on debian-private is in line with that lists policy, which is why I despise discussing things there which should be public. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Kinda weird that we’re all gonna experience climate change as a series of short, apocalyptic videos until eventually it’s your phone that’s recording. (@shocks) signature.asc Description: PGP signature
Re: General Resolution: Liquidate donated assets as soon as possible
On Sat, Jun 18, 2022 at 07:43:06PM -0400, Louis-Philippe Véronneau wrote: > Text of GR > > Donations to the Debian project of assets other than the TO's currency > of choice should be liquidated as soon as possible. > > End Text of GR what does that even mean? also, is there a rationale? and a benefit? and ideas, how to? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Bananas are berries. signature.asc Description: PGP signature
Re: General resolution: Condemn Russian invasion of the Ukraine
On Fri, Apr 08, 2022 at 01:35:14PM -0500, Gunnar Wolf wrote: > Debian does not exist, legally :-) and that's a feature, not a bug. the CCC e.V. association OTOH was formed as a legal entity to protect individuals. it's possible to go both ways to achieve some of the same goals, but the current structures have worked for Debian for almost three decades. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Imagine god created trillions of galaxies but freaks out because some dude kisses another. signature.asc Description: PGP signature
Re: General resolution: Condemn Russian invasion of the Ukraine
On Tue, Apr 05, 2022 at 01:36:02PM -0700, Steve Langasek wrote: > I think this thread has largely petered out, with many people having laid > out the reasons why Debian taking a public position on this is not > necessarily a good idea. > > But I don't think it should go unadddressed that it's quite a bizarre twist > to go from "our priorities are our users and Free Software" to "we care > about evil users". [...] Thank you, Steve, for writing what you wrote. I felt the same but couldn't put it into words this well and I also didn't want to contribute to this thread. But now it's good that you expressed this so well. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The mark of a civilized man is the ability to look at a column of numbers and weep. (Bertrand Russell) signature.asc Description: PGP signature
Re: Results for Voting secrecy
On Mon, Mar 28, 2022 at 07:54:25AM +0200, Christian Kastner wrote: > The latter explicitly reaffirms the status quo, the former does not. I > guess this is why Holger proposed Choice 3. yes. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The devel is in the details. signature.asc Description: PGP signature
Re: Question to all candidates: registering Debian as an organization
On Mon, Mar 21, 2022 at 09:41:49AM +0100, Christian Kastner wrote: > A common pattern to address this within the open source world is to > create a non-profit legal entity, e.g. the FSF Foundation or the GNOME > Foundation. or SPI? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Privacy is a Human Right. (Universal Declaration of Human Rights, article 12.) signature.asc Description: PGP signature
Re: Reaffirm public voting
On Sat, Mar 05, 2022 at 11:42:03AM -0800, Russ Allbery wrote: > [...] Just > > voting on "I want my vote to be secret" without having any information > > about the other properties is IMO completely silly and looses the point. exactly. > Sam's GR intentionally leaves the details open to the Project Secretary to > determine. I understand why people might object to that and would prefer > to require a GR for any change to the process. Yes. > I just wouldn't > characterize that as "rushed" (it's a deliberate choice, and hasn't been > made in a hurry so far as I can tell), so wasn't sure if that was the > objection here or if there was something else I was missing. And I'd call this 'rushed' still. If someone promises foo without explaining how foo should be achieved and then a vote is held to mandate foo, I'd call this 'rushed'. Even if there has been talk about foo for a year, which btw, by Debian standards, is not a long time. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If a monkey hoarded more bananas than it could eat, while most of the other monkeys starved, scientists would study that monkey to figure out what the heck was wrong with it. When humans do it, we put them on the cover of Forbes. signature.asc Description: PGP signature
Re: Alternative: only make vote tally available to DD (or to voters)
Hi Bill, On Fri, Mar 04, 2022 at 07:36:02PM +0100, Bill Allombert wrote: > A suggestion: > > An alternative to secret vote would be to make the vote tallies only > accessible by DD (or more generally to people allowed to vote, whether > they did not not). > > This would still allow voters to check the vote but would not allow > outside parties to use it (unless some DD leaks it, alas). I guess people might sponsor this, so please reword this into an actual proposal for the vote. I'm not sure I'll sponsor it but I think the option should be on the table. :) & thanks. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ :wq signature.asc Description: PGP signature
Re: GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues
hi Bill, On Fri, Mar 04, 2022 at 04:12:44PM +0100, Bill Allombert wrote: > > Anyway, how do we proceed here? > We should merge them! Maybe you could suggest a new wording ? given that my proposal already showed up on https://www.debian.org/vote/2022/vote_001#textc could I please ask you (or anybody else) to look at what's missing compared to your proposal? (sorry to play the lazy card here. you're welcome to draw one as well :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The climate crisis makes a minimum voting age of 18 look so extremely unfair. signature.asc Description: PGP signature
Re: GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues
hi Bill, On Thu, Mar 03, 2022 at 12:10:53AM +0100, Bill Allombert wrote: > Ballot Option > = > > 1) The Debian project decide against changing its voting process at this > time. > > 2) General resolutions that probe developpers opinions about non-technical > issues > outside the social contract are discouraged. > > Rationale > = > > So far no voting scheme that preserve both the integrity of the vote and > the secret of the vote have been proposed. The scheme used for DPL > election does not provide plausible deniability. > > 2. is not made a hard requirement so that it need not be adjudicated by > the Debian secretary. However most of the developers that seconded the first > ballot of GR 2021_002 were experienced developers that would be have been > able to heed the recommendation given in this GR. seems I missed your ballot proposal when I suggested mine in https://lists.debian.org/debian-vote/2022/03/msg00021.html (Message-id: yihtkywt2lhdl...@layer-acht.org>), I'm sorry and I'm blaming information overload everywhere, which is why I'm behind in catching up on reading @-vote. Anyway, how do we proceed here? For now, I'm also seconding your proposal. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ In Europe there are people prosecuted by courts because they saved other people from drowning in the Mediterranean Sea. That is almost as absurd as if there were people being prosecuted because they save humans from drowning in the sea. signature.asc Description: PGP signature
Re: Reaffirm public voting
On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote: > Is init systems GR a political GR? yet there are people maintaining systemd and sysv in public. so what's next, secret maintainers? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ This is a pandemic, not a war. People keep dying even if you surrender. signature.asc Description: PGP signature
Re: Reaffirm public voting
On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote: > On Fri, Mar 04, 2022 at 10:42:51AM +0000, Holger Levsen wrote: > > Reaffirm public voting > > == > > > > Since we can either have secret and intransparent voting, or we can have > > open and transparent voting, the project resolves to leave our voting > > system as it is. > > > > Rationale: > > > > The GR proposal for secret voting is silent on implenentation details, > > probably because secret and transparent voting is, well, impossible to > > achieve fully, so this GR is bound to a similar fate as the 'publish > > debian-private' vote, which was voted for and then was never implemented. > > > > A voting system which is transparent only to some, is undemocratic and > > will lead to few people in the know, which is diagonal to Debians goals > > of openness and transparency. > > > > And then, early 2022 is not the time for rushed changes like this, which > > is also why I explicitly want to see "keep the status quo" on the ballot, > > and not only as "NOTA", but as a real option. > > > > I'm seeking sponsors for this amendment to the current GR. > Assuming you meant this as "this ballot" instead of "this amendment" > (following the new GR flow), I sponsor this. yes, that's what I ment, thanks. Do I need to resent my mail now with this change? :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ We live in a world where teenagers get more and more desperate trying to convince adults to behave like grown ups. signature.asc Description: PGP signature
Reaffirm public voting
Reaffirm public voting == Since we can either have secret and intransparent voting, or we can have open and transparent voting, the project resolves to leave our voting system as it is. Rationale: The GR proposal for secret voting is silent on implenentation details, probably because secret and transparent voting is, well, impossible to achieve fully, so this GR is bound to a similar fate as the 'publish debian-private' vote, which was voted for and then was never implemented. A voting system which is transparent only to some, is undemocratic and will lead to few people in the know, which is diagonal to Debians goals of openness and transparency. And then, early 2022 is not the time for rushed changes like this, which is also why I explicitly want to see "keep the status quo" on the ballot, and not only as "NOTA", but as a real option. I'm seeking sponsors for this amendment to the current GR. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The vision of self driving cars is nothing compared to the vision of no cars at all. signature.asc Description: PGP signature
Re: Amendment: Keep e-mail while allowing other options in addition [Re: GR: Hide Identities of Developers Casting a Particular Vote]
On Wed, Feb 23, 2022 at 04:54:30PM -0800, Don Armstrong wrote: > I propose the following amendment to this ballot option, which if > rejected I propose as its own option: > > modified english/devel/constitution.wml > @@ -266,7 +266,8 @@ earlier can overrule everyone listed later. > > > > -Votes are cast in a manner suitable to the Secretary. > +Votes are cast by email in a manner suitable to the Secretary. > + Non-email methods suitable to the Secretary may be used in addition to > e-mail. > The Secretary determines for each poll whether voters can change > their votes. > > > https://salsa.debian.org/don/webwml/-/commit/9bbc20fed6881fa5b239830cad0939b979bbe300 > > Rationale: e-mail should continue to be an option for casting votes even > while alternative methods of casting ballots might also be allowed. seconded. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ „Copyright is for losers ©™“ (Banksy) signature.asc Description: PGP signature
yes, GRs to change the voting tooling are sensible (Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification)
On Fri, Feb 25, 2022 at 09:34:01AM -0700, Bdale Garbee wrote: > While I'm personally probably more worried about how calls for votes are > disseminated than about how the voting mechanism itself works, the > proposed change feels like a slippery slope towards the possibility that > how voting happens becomes generally less well understood. Requiring a > GR to change the mechanism seems like a completely reasonable way to > both vet the proposed change, and ensure a maximum number of potential > voters understand what's changing. same here. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ :wq signature.asc Description: PGP signature
Re: Secret Ballots: How Secret
On Sun, Feb 13, 2022 at 05:54:45PM +, Holger Levsen wrote: > However that thread has 'secret ballots' in it's subject, so > I still find it very relevant to the topic discussed there, so > I'm slightly put off as being described asking offtopic stuff. actually, not only in the subject, that very mail starts with "Now that we have concluded deciding our GR procedure, I'd like to come back to the question of secret ballots that we decided to defer from the last round" so I'm *puzzled*, to say the least, being characterized as derailing the thread. And furthermore & sadly this confirms my feeling that some want to push 'secret ballots' into Debian... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ I’ve read “Non-Functional Testicles” as retronym for NFT last week and now it can’t be unseen. signature.asc Description: PGP signature
Re: Secret Ballots: How Secret
On Sun, Feb 13, 2022 at 09:50:17AM -0700, Sam Hartman wrote: > Holger asked what I meant by secret. > So I'm starting a separate thread. I'm very fine with this, thank you. > He asked that in a thread discussing stuff related to the project > secretary, and I didn't think an answer belonged there. However that thread has 'secret ballots' in it's subject, so I still find it very relevant to the topic discussed there, so I'm slightly put off as being described asking offtopic stuff. (will reply to the rest of your mail later.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ This is the year of gpg on the desktop! (Gunnar Wolf) signature.asc Description: PGP signature
Re: Secret Ballots: Handling Disagreement with the Secretary
On Fri, Feb 11, 2022 at 02:30:53PM +0100, Philip Hands wrote: > My reason (and maybe Holger's too) is I'd say that there is no > possibility of guaranteeing real permanent absolute secrecy in a vote > that we can practically conduct over the Internet (at least, not one > where the results are also trustworthy), so there is going to be some > sort of compromise, and it is essential to understand the nature of that > compromise in order to come to any conclusion about whether it might be > a good idea to do the the thing that we're really talking about. yes, exactly this. Thank you. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ This too shall pass. signature.asc Description: PGP signature
Re: Secret Ballots: Handling Disagreement with the Secretary
On Sun, Jan 30, 2022 at 03:58:50PM +, Holger Levsen roughly wrote: > On Sat, Jan 29, 2022 at 03:22:24PM -0700, Sam Hartman wrote: > > In my proposal all ballots would be secret, and the secretary would not > > make a determination about that. > what's the definition of 'secret' here? I'd still like to hear an answer to this question and thus I hope it will be addressed in the upcoming proposal. (Transparency note: I reworded my own quote slightly to make it better.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The apocalypse is here now, it’s just not equally distributed. signature.asc Description: PGP signature
+1, all fine (Re: General Resolution: Change the resolution process: results)
On Mon, Jan 31, 2022 at 04:59:35PM +0100, Philip Hands wrote: > Personally, I think it's totally fine for decisions to be made by those > of us that feel like we have an opinion, and for those that don't feel > the need to vote to trust that the outcome from that will be reasonable. > > I don't see how encouraging people to vote who lack either an opinion on > the subject in hand, or the motivation to vote, is supposed to improve > the outcome. agreed on both paragraphs. I also think the amount of participation for this particular vote was good enough. (and I'm thankful Russ will be monitoring future GRs to see how these changes perform in real life.) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ This is a pandemic, not a war. People keep dying even if you surrender. signature.asc Description: PGP signature
Re: Secret Ballots: Handling Disagreement with the Secretary
Hi Sam, On Sat, Jan 29, 2022 at 03:22:24PM -0700, Sam Hartman wrote: > In my proposal all ballots would be secret, and the secretary would not > make a determination about that. how do you define 'secret' here? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make racists afraid again. signature.asc Description: PGP signature
Re: GR: Change the resolution process (2021-11-25 revision)
I second this. On Thu, Nov 25, 2021 at 07:25:45PM -0800, Russ Allbery wrote: > Section 4.2.4 > - > > Strike the sentence "The minimum discussion period is 2 weeks, but may be > varied by up to 1 week by the Project Leader." (A modified version of > this provision is added to section A below.) Add to the end of this > point: > > The default option is "None of the above." > > Section 4.2.5 > - > > Replace "amendments" with "ballot options." > > Section 5.1.5 > - > > Replace in its entirety with: > > Propose General Resolutions and ballot options for General > Resolutions. When proposed by the Project Leader, sponsors for the > General Resolution or ballot option are not required; see §4.2.1. > > Section 5.2.7 > - > > Replace "section §A.6" with "section §A.5". > > Section 6.1.7 > - > > Replace "section §A.6" with "section §A.5". > > Add to the end of this point: > > There is no casting vote. If there are multiple options with no > defeats in the Schwartz set at the end of A.5.8, the winner will be > randomly chosen from those options, via a mechanism chosen by the > Project Secretary. > > Section 6.3 > --- > > Replace 6.3.1 in its entirety with: > > 1. Resolution process. > >The Technical Committee uses the following process to prepare a >resolution for vote: > >1. Any member of the Technical Committee may propose a resolution. > This creates an initial two-option ballot, the other option > being the default option of "None of the above". The proposer > of the resolution becomes the proposer of the ballot option. > >2. Any member of the Technical Committee may propose additional > ballot options or modify or withdraw a ballot option they > proposed. > >3. If all ballot options except the default option are withdrawn, > the process is canceled. > >4. Any member of the Technical Committee may call for a vote on the > ballot as it currently stands. This vote begins immediately, but > if any other member of the Technical Committee objects to > calling for a vote before the vote completes, the vote is > canceled and has no effect. > >5. Two weeks after the original proposal the ballot is closed to > any changes and voting starts automatically. This vote cannot be > canceled. > >6. If a vote is canceled under point 6.3.1.4 later than 13 days > after the initial proposed resolution, the vote specified in > point 6.3.1.5 instead starts 24 hours after the time of > cancellation. During that 24 hour period, no one may call for a > vote. > > Add a new paragraph to the start of 6.3.2 following "Details regarding > voting": > >Votes are decided by the vote counting mechanism described in >section §A.5. The voting period lasts for one week or until the >outcome is no longer in doubt assuming no members change their >votes, whichever is shorter. Members may change their votes until >the voting period ends. There is a quorum of two. The Chair has a >casting vote. The default option is "None of the above". > > Strike "The Chair has a casting vote." from the existing text and make the > remaining text a separate, second paragraph. > > In 6.3.3, replace "amendments" with "ballot options." > > Add, at the end of section 6.3, the following new point: > > 7. Proposing a general resolution. > >When the Technical Committee proposes a general resolution or a >ballot option in a general resolution to the project under point >4.2.1, it may delegate the authority to withdraw, amend, or make >minor changes to the ballot option to one of its members. If it >does not do so, these decisions must be made by resolution of the >Technical Committee. > > Section A > - > > Replace A.0 through A.4 in their entirety with: > > A.0. Proposal > > 1. The formal procedure begins when a draft resolution is proposed and >sponsored, as required. A draft resolution must include the text of >that resolution and a short single-line summary suitable for >labeling the ballot choice. > > 2. This draft resolution becomes a ballot option in an initial >two-option ballot, the other option being the default option, and >the proposer of the draft resolution becomes the proposer of that >ballot option. > > A.1. Discussion and amendment > > 1. The discussion period starts when a draft resolution is proposed >and sponsored. The minimum discussion period is 2 weeks. The >maximum discussion period is 3 weeks. > > 2. A new ballot option may be proposed and sponsored according to the >requirements for a new
Re: GR: Change the resolution process (corrected)
I second this. On Tue, Nov 23, 2021 at 09:53:50AM +0200, Wouter Verhelst wrote: > > On Mon, Nov 22, 2021 at 05:15:34PM +0200, Wouter Verhelst wrote: > > [...] > > > Section A > > > - > > > > > > Replace section A as per Russ' proposal, with the following changes: > > > > > > A.1.1. Strike the sentence "The maximum discussion period is 3 weeks". > > > > This should additionally say, > > > > Replace the sentence "The minimum discussion period is 2 weeks." by > > "The initial discussion period is 1 week." > > > > as my proposal does not allow the DPL to reduce the discussion time, and > > instead reduces the discussion time always, relying on the time > > extension procedure to lengthen it, if required (which the DPL can use > > without seconds, once). > > > > Since both Russ and myself seem to be having issues here, in order to > > better understand the proposed changes, I have made > > https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml > > (which is a version of the constitution with the changes as proposed by > > Russ) and > > https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml > > (with the required changes as per my proposal). While doing so, I > > realized there were a few cross-references still that I needed to update > > as well. > > > > Russ, please review the patch I wrote, so as to make sure I haven't made > > any mistakes in your proposal. > > > > All this changes my proposal to the below. I would appreciate if my > > seconders would re-affirm that they agree with the changes I propose, > > and apologies for the mess. > > > > Rationale > > = > > > > Much of the rationale of Russ' proposal still applies, and indeed this > > amendment builds on it. However, the way the timing works is different, > > on purpose. > > > > Our voting system, which neither proposal modifies, as a condorcet > > voting mechanism, does not suffer directly from too many options on the > > ballot. While it is desirable to make sure the number of options on the > > ballot is not extremely high for reasons of practicality and voter > > fatigue, it is nonetheless of crucial importance that all the *relevant* > > options are represented on the ballot, so that the vote outcome is not > > questioned for the mere fact that a particular option was not > > represented on the ballot. Making this possible requires that there is > > sufficient time to discuss all relevant opinions. > > > > Russ' proposal introduces a hard limit of 3 weeks to any and all ballot > > processes, assuming that that will almost always be enough, and relying > > on withdrawing and restarting the voting process in extreme cases where > > it turns out more time is needed; in Russ' proposal, doing so would > > increase the discussion time by another two weeks at least (or one if > > the DPL reduces the discussion time). > > > > In controversial votes, I believe it is least likely for all ballot > > proposers to be willing to use this escape hatch of withdrawing the vote > > and restarting the process; and at the same time, controversial votes > > are the most likely to need a lot of discussion to build a correct > > ballot, which implies they would be most likely to need some extra time > > -- though not necessarily two more weeks -- for the ballot to be > > complete. > > > > At the same time, I am not insensitive to arguments of predictability, > > diminishing returns, and process abuse which seem to be the main > > arguments in favour of a hard time limit at three weeks. > > > > For this reason, my proposal does not introduce a hard limit, and > > *always* makes it theoretically possible to increase the discussion > > time, but does so in a way that extending the discussion time becomes > > harder and harder as time goes on. I believe it is better for the > > constitution to allow a group of people to have a short amount of extra > > time so they can finish their proposed ballot option, than to require > > the full discussion period to be restarted through the withdrawal and > > restart escape hatch. At the same time, this escape hatch is not > > removed, although I expect it to be less likely to be used. > > > > The proposed mechanism sets the initial discussion time to 1 week, but > > allows it to be extended reasonably easily to 2 or 3 weeks, makes it > > somewhat harder to reach 4 weeks, and makes it highly unlikely (but > > still possible) to go beyond that. > > > > Text of the GR > > == > > > > The Debian Developers, by way of General Resolution, amend the Debian > > constitution under point 4.1.2 as follows. This General Resolution > > requires a 3:1 majority. > > > > Sections 4 through 7 > > > > > > Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6, > > where relevant. > > > > Section A > > - > > > > Replace section A as per Russ' proposal, with the following
Re: GR: Change the resolution process (corrected)
tl;dr: I second this. On Mon, Nov 22, 2021 at 05:15:34PM +0200, Wouter Verhelst wrote: > Text of the GR > == > > The Debian Developers, by way of General Resolution, amend the Debian > constitution under point 4.1.2 as follows. This General Resolution > requires a 3:1 majority. > > Sections 4 through 7 > > > Same changes as in Russ' proposal > > Section A > - > > Replace section A as per Russ' proposal, with the following changes: > > A.1.1. Strike the sentence "The maximum discussion period is 3 weeks". > > A.1.4. Strike in its entirety > > A.1.5. Rename to A.1.4. > > A.1.6. Strike in its entirety > > A.1.7. Rename to A.1.5. > > After A.2, insert: > > A.3. Extending the discussion time. > > 1. When less than 48 hours remain in the discussion time, any Developer >may propose an extension to the discussion time, subject to the >limitations of §A.3.3. These extensions may be seconded according to >the same rules that apply to new ballot options. > > 2. As soon as a time extension has received the required number of >seconds, these seconds are locked in and cannot be withdrawn, and the >time extension is active. > > 3. When a time extension has received the required number of seconds, >its proposers and seconders may no longer propose or second any >further time extension for the same ballot, and any further seconds >for the same extension proposal will be ignored for the purpose of >this paragraph. In case of doubt, the Project Secretary decides how >the order of seconds is determined. > > 4. The first two successful time extensions will extend the discussion >time by one week; any further time extensions will extend the >discussion time by 72 hours. > > 5. Once the discussion time is longer than 4 weeks, any Developer may >object to further time extensions. Developers who have previously >proposed or seconded a time extension may object as well. If the >number of objections outweigh the proposer and their seconders, >including seconders who will be ignored as per §A.3.3, the time >extension will not be active and the discussion time does not change. > > A.3. Rename to A.4. > > A.4. Rename to A.5. > > A.5. Rename (back) to A.6. seconded. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Stop saying that we are all in the same boat. We’re all in the same storm. But we’re not all in the same boat. signature.asc Description: PGP signature
Re: GR: Change the resolution process (corrected)
On Sun, Nov 21, 2021 at 03:41:18PM -0800, Russ Allbery wrote: > > Because of this (and others), can I suggest that the ballot option be > > specified as a wdiff to the existing constitution? > Is there a Git repository somewhere with the canonical copy of the > constitution that I an start from? I assume it's somewhere in the > www.debian.org machinery, which is something I've never worked with before > and am not sure how to get at. I *believe* you'll find it in english/devel/constitution.wml in g...@salsa.debian.org:webmaster-team/webwml (*After* the GR when the change is actually going to be made please note that there are files like english/devel/constitution.1.$x.wml...) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Change is coming whether you like it or not. signature.asc Description: PGP signature
Re: GR: Change the resolution process (corrected)
tl;dr: I second this. On Sat, Nov 20, 2021 at 10:04:07AM -0800, Russ Allbery wrote: > Effect of the General Resolution > > > The Debian Developers, by way of General Resolution, amend the Debian > constitution under point 4.1.2 as follows. This General Resolution > requires a 3:1 majority. > > Section 4.2.4 > - > > Strike the sentence "The minimum discussion period is 2 weeks, but may be > varied by up to 1 week by the Project Leader." (A modified version of > this provision is added to section A below.) Add to the end of this > point: > > The default option is "None of the above." > > Section 4.2.5 > - > > Replace "amendments" with "ballot options." > > Section 5.1.5 > - > > Replace in its entirety with: > > Propose General Resolutions and ballot options for General > Resolutions. When proposed by the Project Leader, sponsors for the > General Resolution or ballot option are not required; see §4.2.1. > > Section 5.2.7 > - > > Replace "section §A.6" with "section §A.5". > > Section 6.1.7 > - > > Replace "section §A.6" with "section §A.5". > > Add to the end of this point: > > There is no casting vote. If there are multiple options with no > defeats in the Schwartz set at the end of A.5.8, the winner will be > randomly chosen from those options, via a mechanism chosen by the > Project Secretary. > > Section 6.3 > --- > > Replace 6.3.1 in its entirety with: > > 1. Resolution process. > >The Technical Committee uses the following process to prepare a >resolution for vote: > >1. Any member of the Technical Committee may propose a resolution. > This creates an initial two-option ballot, the other option > being the default option of "Further discussion." The proposer > of the resolution becomes the proposer of the ballot option. > >2. Any member of the Technical Committee may propose additional > ballot options or modify or withdraw a ballot option they > proposed. > >3. If all ballot options except the default option are withdrawn, > the process is canceled. > >4. Any member of the Technical Committee may call for a vote on the > ballot as it currently stands. This vote begins immediately, but > if any other member of the Technical Committee objects to > calling for a vote before the vote completes, the vote is > canceled and has no effect. > >5. Two weeks after the original proposal the ballot is closed to > any changes and voting starts automatically. This vote cannot be > canceled. > >6. If a vote is canceled under point 6.3.1.4 later than 13 days > after the initial proposed resolution, the vote specified in > point 6.3.1.5 instead starts 24 hours after the time of > cancellation. During that 24 hour period, no one may call for a > vote. > > Add a new paragraph to the start of 6.3.2 following "Details regarding > voting": > >Votes are decided by the vote counting mechanism described in >section §A.5. The voting period lasts for one week or until the >outcome is no longer in doubt assuming no members change their >votes, whichever is shorter. Members may change their votes until >the voting period ends. There is a quorum of two. The Chair has a >casting vote. The default option is "Further discussion." > > Strike "The Chair has a casting vote." from the existing text and make the > remaining text a separate, second paragraph. > > In 6.3.3, replace "amendments" with "ballot options." > > Add, at the end of section 6.3, the following new point: > > 7. Proposing a general resolution. > >When the Technical Committee proposes a general resolution or a >ballot option in a general resolution to the project under point >4.2.1, it may delegate the authority to withdraw, amend, or make >minor changes to the ballot option to one of its members. If it >does not do so, these decisions must be made by resolution of the >Technical Committee. > > Section A > - > > Replace A.0 through A.4 in their entirety with: > > A.0. Proposal > > 1. The formal procedure begins when a draft resolution is proposed and >sponsored, as required. A draft resolution must include the text of >that resolution and a short single-line summary suitable for >labeling the ballot choice. > > 2. This draft resolution becomes a ballot option in an initial >two-option ballot, the other option being the default option, and >the proposer of the draft resolution becomes the proposer of that >ballot option. > > A.1. Discussion and amendment > > 1. The discussion period starts when a
Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes
On Mon, Nov 08, 2021 at 10:38:01AM -0700, Sam Hartman wrote: > Holger> all of this and additionally personally I'd also find it > Holger> disrespectful to hijack/piggyback (on) Russ' work. > I'm frustrated reading this message because it sounds like you've jumped > to the assumption that I'm hijacking Russ's work without coordinating > with him. I'm frustrated you read "I would find it disrectful" as disrespectful. I didn't know whether you coordinated with Russ and I did not claim anything in that regard. *I* find it disrespectful to piggyback on Russ' proposal and I respect you and Russ disagree with me. > I hope that in similar future situations, you ask rather than jumping to > disrespect. Same same. And, I'd hope that in the future a GR on secret ballots will fail. Because, they won't be secret (because they cannot be in technical terms) and they would fuel a cabal. And there should be less cabals in Debian. If you find this opinion disrespectful as well... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Life may not be the party we hoped for, but while we're here we might as well dance! signature.asc Description: PGP signature
Re: Do we want to Handle Secret Ballots in the same GR as Voting Changes
On Mon, Nov 08, 2021 at 12:12:33PM -0500, Louis-Philippe Véronneau wrote: > > I'd like to ask the community whether we'd like to handle secret ballots > > now, or in a separate GR. > I'd tend to be in favor of making this a separate GR. [...] > Adding yet another change to this proposal would only make things more > complex and make the issues at hand harder to understand. all of this and additionally personally I'd also find it disrespectful to hijack/piggyback (on) Russ' work. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Bottled water companies don't produce water, they produce plastic bottles. signature.asc Description: PGP signature
Re: Renaming the FTP Masters
On Fri, Nov 05, 2021 at 03:52:01PM -0700, Felix Lechner wrote: > It was impromptu. The mail was intentional only in the sense that I > hoped to find a topic to unite people. (Who likes slavery, anway?) obviously everybody who's not instantly supporting renaming ftpmaster :) I think you got a *lot* to learn about how to unite people, this thread is a pretty "good" example how not to do this and rather alienate them. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The upcoming clima apocalypse is the big elephant in every room now. signature.asc Description: PGP signature
Re: Renaming the FTP Masters
On Thu, Nov 04, 2021 at 03:28:07PM -0700, Felix Lechner wrote: > [...] We effectively live > under martial law you mean, people in Debian die? I'm speechless and pretty unimpressed. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ We live in a world where teenagers get more and more desperate trying to convince adults to behave like grown ups. signature.asc Description: PGP signature
Re: Opposing strict time limits
hi, i'm just following along, so please excuse my brief comments from the sidelines... On Mon, Oct 25, 2021 at 11:15:18AM -0600, Sam Hartman wrote: > Wouter and I are going to disagree on this, but I actually think that > the work I did during the latest systemd vote significantly helped move > the discussion forward. By trying to listen to various sides and trying > to present several options I think I managed to frame the process in a > way that was more constructive. > > I'm sure that process can be refined. But I'd rather see DPLs do that > work more rather than less. > > I also don't want to see that work restricted to the DPL. In many cases > I'd rather see ballot options drafted by people in the middle rather > than by strong proponents of a polarized position. actually I'm not so sure I want the DPL to be regularily involved in such activities. Undoubtfully these activities are usefull, but I fear they might be less useful when done by the DPL... [this is a generic remark, not based on the systemd vote.] > 1) Remember that we want to move toward secret ballots. Do *we*, really? I'm not sure I like the idea but at least I recall some people discussing this. Also I'm pretty sure many people^wDebian members have not even heard this being discussed. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If you upload your address book to "the cloud", I don't want to be in it. signature.asc Description: PGP signature
+1 (was Re: Draft proposal for resolution process changes)
On Tue, Sep 28, 2021 at 08:50:08PM -0700, Russ Allbery wrote: > [...] My goal is a proposal that anyone > can support as long as they agree that: > > * We currently need an explicit and clearly-specified decision-making > process for the Technical Committee and the Developers via General > Resolution. > * The current systems for both are confusing and somewhat unclear, and > have loopholes that have caused frustration and perceptions of > unfairness in the past. > * This proposal is an incremental improvement in clarity and fairness > without losing any valuable properties of the existing systems. > > The one trade-off decision that I'm explicitly making is that, given the > past problems and complaints about issues with vote timing, I've made the > timing of votes less flexible in order to make them more predictable. sounds all very good to me, many thanks for driving this, Russ! > I would love for us to make more decisions, more quickly, and be more > willing to change them later based on further experience. I would love > for us to make more mistakes and learn from them, instead of being > unwilling to commit or to risk making anyone unhappy and thus postpone > decisions until they're no longer exciting or motivating and have become > mere drudgery. YES! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Live may not be the party we hoped for, but while we're here we might as well dance! signature.asc Description: PGP signature
+1 (adding voting question to NM templates) Re: What does FD Mean
On Sun, Apr 11, 2021 at 10:57:27PM +0200, Pierre-Elliott Bécue wrote: > I've discussed with another Front Desk member about adding a question on > our voting system in the nm templates. > > The idea being to make sure if people have questions, they get some > answers, and otherwise relevant pointers to doc. I like that idea, thanks for bringing it up! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ Der Mensch is' gut, aber die Leut' san a G'sindel! signature.asc Description: PGP signature
Re: Making the RMS resolution a Secret Ballot
On Fri, Apr 09, 2021 at 05:55:48PM +, Holger Levsen wrote: > That said, I think it's a *very* bad idea to change the vote procedure > during an ongoing vote. Really *bad* idea and precedence. Double more > so on a vote with shortened discussion period. > > (plus secret voting is a *really really really* hard problem.) > > > I also don't fear that much of a changed outcome. It seems 117 Debian > people (most of them voters I believe) signed > https://rms-open-letter.github.io/ > and https://vote.debian.org/~secretary/gr_rms/ counts 268 valid votes, > so, based on that *and* on the discussion here now and in the past, I > don't think a few people who fear to vote what they think because then > their opinion could become public will make a big difference. footnote1: I'm sorry if this sounded like I might disregarded those very real fears and hate mail and worse. By all means not. But, as written right here...(!) > Most people > made public statements already anyway. Also: they vote has been started > as a public vote, it was shortened as a public vote and it's technically > complete unclear what "secret" would mean here (and to whom and for how long). > > But, to be clear, change outcome of the vote is not my concern here. Changing > the way we vote, in a rush, from what will be perceived as a cabal, is my > concern. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ signature.asc Description: PGP signature
Re: Making the RMS resolution a Secret Ballot
On Fri, Apr 09, 2021 at 01:12:26PM -0400, Sam Hartman wrote: > On another list, there was discussion of the DPL encouraging the > secretary to make the vote on the rms GR secret. I'm not sure this is not leaking. > I argued on another list that[...] > Several people agreed with me, ande one person disagreed. Again, I'd consider this leaking from that other list which has a no-leaking policy. If you don't like that, better don't use that other list. (I unsubscribed because I've been (too) annoyed by discussions happening there which should happen in public.) That said, I think it's a *very* bad idea to change the vote procedure during an ongoing vote. Really *bad* idea and precedence. Double more so on a vote with shortened discussion period. (plus secret voting is a *really really really* hard problem.) I also don't fear that much of a changed outcome. It seems 117 Debian people (most of them voters I believe) signed https://rms-open-letter.github.io/ and https://vote.debian.org/~secretary/gr_rms/ counts 268 valid votes, so, based on that *and* on the discussion here now and in the past, I don't think a few people who fear to vote what they think because then their opinion could become public will make a big difference. Most people made public statements already anyway. Also: they vote has been started as a public vote, it was shortened as a public vote and it's technically complete unclear what "secret" would mean here (and to whom and for how long). But, to be clear, change outcome of the vote is not my concern here. Changing the way we vote, in a rush, from what will be perceived as a cabal, is my concern. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ I'm looking forward to Corona being a beer again and Donald a duck. signature.asc Description: PGP signature
Re: Debian-vote: GRs, discussion and voting periods - a plea for calm
someone brought this up on IRC and I replied... [23:01] < h01ger> he apologized in private, so i'm fine. mistakes happen all the time. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ The greatest danger in times of turbulence is not the turbulence; it is to act with yesterdays logic. (Peter Drucker) signature.asc Description: PGP signature
Re: Debian-vote: GRs, discussion and voting periods - a plea for calm
On Sun, Apr 04, 2021 at 06:36:40PM +, Andrew M.A. Cater wrote: > I _am_ a member of the community team. oh dear. [I'm not really able to express what I feel having a private mail exposed by you. I hope for a honest mistake but even then I'd be disappointed. I'll leave it at this.] because you cannot have community if you disrespect privacy. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ signature.asc Description: PGP signature
Re: New option for the RMS/FSF GR: reaffirm the values of the majority
On Sat, Apr 03, 2021 at 11:51:29PM +0100, Simon McVittie wrote: > It seems highly likely that the message to which I'm replying was not > sent or authorized by Enrico, and that its sender is trying to mislead > Debian members by impersonating a prominent and respected developer. IRC revealed that the key used to sign this message might or might not be the same as the one used to sign a message on April 1st. IOW: I do "blame" Enrico for that mail, too. I also think it was one of the best mails in these threads, by far. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ I'm looking forward to Corona being a beer again and Donald a duck. signature.asc Description: PGP signature
Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 12:44:02AM +0200, Salvo Tomaselli wrote: > There are non-DD people who maintain more packages and with higher total > popcon than DDs, but aren't DD because didn't bother to jump through all the > several hoops to become a DD. > > If you do not want DMs, make a proposal and vote to kick all the DMs out > from Debian. If it passes then be ready to adopt a few hundreds of packages > or see debian crash and burn. sigh. I'm quite annoyed at people judging other people due to their 'status' in Debian instead of what they write (or actually do). The above quoted mail is a sad example why. To all non-DD, non-uploaders, non-technical people, non-foo: Thank you for your work on Debian! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ Because things are the way they are, things will not stay the way they are. (Bertolt Brecht) signature.asc Description: PGP signature
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > TEXT OF OPTION 5 > > Debian refuses to participate in and denounces the witch-hunt against Richard > Stallman, the Free Software Foundation, and the members of the board of the > Free Software Foundation. > I'd sponsor this if this were actually neutrally worded like "Debian refuses to participate in the discussion of Richard Stallman, the Free Software Foundation, and the members of the board of the Free Software Foundation." Though even that is a statement. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ No future. signature.asc Description: PGP signature
spoiler alert (was Re: Announcing new decision making procedures for Debian)
On Wed, Mar 31, 2021 at 07:31:12PM -0400, Louis-Philippe Véronneau wrote: > Just to be crystal clear if it wasn't already, this is all satire. I think, aeh, hope, this is the funniest message today. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ We are done with ‘world leaders’. Countries are on fire. Cities are drowning. People are dying. This is what scientists and activists have been warning the world and politicians about. It’s here. We ARE facing the impacts of the climate crisis. Forget about the future, it’s now. fridays for future - https://nitter.net/fff_digital/status/1304520941012242432 signature.asc Description: PGP signature
Re: Amendment to RMS/FSF GR: Option 4, assert the need to learn and grow from recent events
On Tue, Mar 30, 2021 at 11:28:47PM +0100, Jonathan Wiltshire wrote: > CHOICE TEXT FOLLOWS: > > This is a position statement of the Debian Developers in accordance with > our constitution, section 4.1.5. > > The Developers firmly believe that leaders in any prominent organisation > are, and should be, held to the highest standards of accountability. > > We are disappointed that issues of transparency and accountability in the > governance of the Free Software Foundation have led to unresolved and > serious complaints of impropriety by its founder Richard Stallman over a > number of years whilst in the position of president and as a member of the > board. In particular, we are deeply concerned that the board saw fit to > reinstate him without properly considering the effect of its actions on > those complainants. > > The Developers acknowledge that people make mistakes but believe that where > those people are in leadership positions, they must be held accountable for > their mistakes. We believe that the most important part of making mistakes > is learning from them and changing behaviour. We are most concerned that > Richard and the board have not sufficiently acknowledged or learned from > issues which have affected a large number of people and that Richard > remains a significant influence on both the FSF board and the GNU project. > > We call upon the Free Software Foundation to further steps it has taken in > March 2021 to overhaul governance of the organisation, and to work > tirelessly to ensure its aim is fulfilled. We believe that only through > properly accountable governance can members of an organisation ensure their > voice is heard. The Free Software Foundation must do everything in its > power to protect its staff and members, and the wider community, including > a robust and transparent process for dealing with complaints. > > We urge Richard Stallman and the remaining members of the board which > reinstated him, to consider their positions. > > The Developers are proud that contributors to free software come from all > walks of life and that our diverse experience and opinions are a strength > of software freedom. But we must never cease in our efforts to ensure that > all contributors are treated with respect, and that they feel safe and > secure in our communities - including when we meet in person. > > END CHOICE TEXT Seconded. Thanks, Jonathan! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ Die Faktenlage bzgl. Klimakatastrophe ist so eindeutig und die Folgen sind so schwerwiegend, dass Parteien und Organisationen, die immer noch wirksame Maß- nahmen dagegen behindern, als verbrecherisch einzustufen sind. signature.asc Description: PGP signature
Re: Amendement to GR Statement regarding Stallman's readmission to the FSF board
On Mon, Mar 29, 2021 at 02:51:59PM +0200, Santiago R.R. wrote: > Choice X: Debian is unable to collaborate with FSF > > === 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 actions and consider this feedback > in future actions. Unfortunately, the way Richard Stallman announced his > return to the board lacks any acknowledgement of this kind of thought process. > We are deeply disappointed that the FSF board elected him as 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 belatedly conveyed [0] to FSF’s staff and > supporters. > > We believe this step and how it was communicated sends a 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 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. > > Therefore, in the current situation, the Debian Project is 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 > > === End text === Seconded. Thanks, Santiago & Zlatan! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ This is the year of gpg on the desktop! (Gunnar Wolf) signature.asc Description: PGP signature
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
On Sat, Mar 27, 2021 at 10:12:47PM -0500, Michael Lustfield wrote: > Choice X: > > The Debian Project disapproves of recent and past actions taken by FSF. With > regards to the latest action (re-acceptance of RMS to the board), it now > chooses to cut ties with the foundation. The Debian Project encourages members > impacted by recent actions to sign the open letter. Seconded. (Though I'm not fully sure the forms is correct, but maybe it's sufficient?!) And then, what does 'cut ties with the foundation' mean exactly? We certainly won't stop shipping stuff where the copyright belongs to the FSF 8-) So probably this should be specified a bit more? > I would personally choose this because: > - I have many problems with FSF, beyond this particular concern. > - The concerns raised are irrelevant to me, but other concerns remain > relevant. > - Many (including DD's) clearly feel personally attacked by recent actions. > > tl;dr -- This is just Choice 2 with a separation from FSF. I'm not sure how I'd rank this, but I do think this is an important and new choice for the GR. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ Der Mensch is' gut, aber die Leut' san a G'sindel! signature.asc Description: PGP signature
Re: Amendment to GR on RMS rejoining FSF
On Sat, Mar 27, 2021 at 12:17:58AM +0530, Sruthi Chandran wrote: > > 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. Thanks, Sruthi! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ I'm looking forward to Corona being a beer again and Donald a duck. signature.asc Description: PGP signature
Re: Willingness to share a position statement?
On Wed, Mar 24, 2021 at 12:38:25PM +, Steve McIntyre wrote: > 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. well said, I agree with every word. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ Historians have a word for Germans who joined the Nazi party, not because they hated Jews, but out of hope for restored patriotism, or a sense of economic anxiety, or a hope to preserve their religious values, or dislike of their opponents, or raw political opportunism, or convenience, or ignorance, or greed. That word is "Nazi". Nobody cares about their motives anymore. signature.asc Description: PGP signature
Re: How can we make Debian packaging more standardised?
On Fri, Mar 19, 2021 at 02:05:35PM -0400, Louis-Philippe Véronneau wrote: > Even if we don't ultimately enforce it, being able to point people an > officially recommended way to create packages in Debian would be a large > step forward. I'd expect this to be found in https://salsa.debian.org/debian/developers-reference and by no coincidence any DD can commit to this repo and MRs asking for reviews are also very much welcome! https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#best-practices-for-debian-rules is the specific chapter in need of patches. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ The system isn't broken. It was built this way. signature.asc Description: PGP signature
Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20
On Fri, May 22, 2020 at 02:40:55PM +0200, Martin Zobel-Helas wrote: > This is a draft for a GR I would like to propose. > > Cancel this year's in-person Debian Developers Conference DebConf20 [...] I'd second that, thanks. However, I would prefer if the DebConf organizers cancel themselves. (And I would also prefer we would wake up soon and this nightmare is over. I just don't think that this will happen anytime soon.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Q to all candidates: NEW queue
On Sat, Mar 28, 2020 at 09:50:41AM +, Simon McVittie wrote: > On Fri, 27 Mar 2020 at 23:06:55 +0000, Holger Levsen wrote: > > another option would be 'unstable-proposed' (or whatever) where packages get > > uploaded to, and which only gets moved to 'unstable' if they don't fail > > piuparts, > > autopkgtests (plain build tests) and so forth... > Do you mean this to be for all package, like Ubuntu does (they run the > unstable->testing migration with a 0-day delay, all packages get uploaded > into the equivalent of unstable, and users of their development branch > are actually getting the equivalent of testing), or do you mean just for > source-NEW and/or binary-NEW packages? for all, including *-NEW. why should ftpmaster/anyone look at a package which fails automated test? (well, anyone except the maintainers of said package.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Q to all candidates: NEW queue
hi, another option would be 'unstable-proposed' (or whatever) where packages get uploaded to, and which only gets moved to 'unstable' if they don't fail piuparts, autopkgtests (plain build tests) and so forth... humans shouldn't look at stuff robots don't wanna see. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Last minute cominbations G+D and/or G+E
On Thu, Dec 05, 2019 at 11:59:36AM +, Ian Jackson wrote: > Here is the formal version of this proposal. (My previous mail wasn't > signed.) > > I hereby propose it and hope to have it on the ballot, given that > there are enough seconds. I do *not* intend to replace the existing > proposal D. > > > Differences from the version I posted yesterday: > * Added a title > * Typos and grammar fixes > * Numbering fixed > > Kurt, you can make the HTML for this as follows: > * c the HTML from proposal D > * Adding the new title > * Replacing the PRINCIPLES section by c the text > from G, and numbering the paragraphs as clauses > * Renumbering (adding 3 to each clause number) > > (I constructed this by dumping the w3m of D from the vote page and > reconciling all the output from `git diff --color --word-diff'.) > > > For the avoidance of any doubt, if we can get this onto the ballot I > intend to rank it ahead of my own D. > > Nevertheless I want to retain my existing D because its weaker > statement of principles may well be attractive to a wider audience, > because it was a negotiated compromise which had input from a variety > of people with different opinions, and because there is not time now > to find out whether the people who supported D would prefer this one. > > Thanks, > Ian. > > > Title: Support portability, without blocking progress > > PRINCIPLES > > 1. The Debian project reaffirms its commitment to be the glue that > binds and integrates different software that provides similar or > equivalent functionality, with their various users, be them humans or > other software, which is one of the core defining traits of a > distribution. > > 2. We consider portability to different hardware platforms and > software stacks an important aspect of the work we do as a > distribution, which makes software architecturally better, more robust > and more future-proof. > > 3. We acknowledge that different upstream projects have different > views on software development, use cases, portability and technology > in general. And that users of these projects weight tradeoffs > differently, and have at the same time different and valid > requirements and/or needs fulfilled by these diverse views. > > 4. Following our historic tradition, we will welcome the integration > of these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our > distribution, by reconciling these conflicts via technical means, as > long as there are people willing to put in the effort. > > 5. This enables us to keep serving a wide range of usages of our > distribution (some of which might be even unforeseen by us). From > servers, to desktops or deeply embedded; from general purpose to very > specifically tailored usages. Be those projects hardware related or > software based, libraries, daemons, entire desktop environments, or > other parts of the software stack. > > SYSTEMD DEPENDENCIES > > 6. Ideally, packages should be fully functional with all init systems. This > means (for example) that daemons should ship traditional init scripts, or use > other mechanisms to ensure that they are started without systemd. It also > means > that desktop software should be installable, and ideally fully functional, > without systemd. > > 7. So failing to support non-systemd systems, where no such support is > available, is a bug. But it is *not* a release-critical bug. Whether the > requirement for systemd is recorded as a formal bug in the Debian bug system, > when no patches are available, is up to the maintainer. > > 8. When a package has reduced functionality without systemd, this should not > generally be documented as a (direct or indirect) Depends or Recommends on > systemd-sysv. This is because with such dependencies, installing such a > package > can attempt to switch the init system, which is not what the user wanted. For > example, a daemon with only a systemd unit file script should still be > installable on a non-systemd system, since it could be started manually. > > One consequence of this is that on non-systemd systems it may be possible to > install software which will not work, or not work properly, because of an > undeclared dependency on systemd. This is unfortunate but trying to switch the > user's init system is worse. We hope that better technical approaches can be > developed to address this. > > 9. We recognise that some maintainers find init scripts a burden and we hope > that the community is able to find ways to make it easier to add support for > non-default init systems. Discussions about the design of such systems should > be friendly and cooperative, and if suitable arrangements are developed they > should be supported in the usual ways within Debian. > > CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED > > 10. Failing to support non-systemd systems when such support is available, or > offered in the form of
Re: Last minute cominbations G+D and/or G+E
On Wed, Dec 04, 2019 at 05:14:38PM +, Ian Jackson wrote: > Here is what I think Guillem's plus mine looks like. > > NB that I may have reintroduced typos which have been fixed on the > website version. I haven't had time to check that. > > -8<- > > Title: Support non-systemd systems, without blocking progress > > PRINCIPLES > > 1. The Debian project reaffirms its commitment to be the glue that binds >and integrates different software that provides similar or equivalent >functionality, with their various users, be them humans or other software, >which is one of the core defining traits of a distribution. > > 2. We consider portability to different hardware platforms and software >stacks an important aspect of the work we do as a distribution, which >makes software architecturally better, more robust and more future-proof. > > 3. We acknowledge that different upstream projects have different views on >software development, use cases, portability and technology in general. >And that users of these projects weight tradeoffs differently, and have >at the same time different and valid requirements and/or needs fulfilled >by these diverse views. > > 4. Following our historic tradition, we will welcome the integration of >these diverse technologies which might sometimes have conflicting >world-views, to allow them to coexist in harmony within our distribution, >by reconciling these conflicts via technical means, as long as there >are people willing to put in the effort. > > 5. This enables us to keep serving a wide range of usages of our distribution >(some of which might be even unforeseen by us). From servers, to desktops >or deeply embedded; from general purpose to very specifically tailored >usages. Be those projects hardware related or software based, libraries, >daemons, entire desktop environments, or other parts of the software >stack. > > SYSTEMD DEPENDENCIES > > 3. Ideally, packages should should be fully functional with all init >systems. This means (for example) that daemons should ship >traditional init scripts, or use other mechanisms to ensure that >they are started without systemd. It also means that desktop >software should be installable, and ideally fully functional, >without systemd. > > 4. So failing to support non-systemd systems, where no such support is >available, is a bug. But it is *not* a release-critical bug. >Whether the requirement for systemd is recorded as a formal bug in >the Debian bug system, when no patches are available, is up to the >maintainer. > > 5. When a package has reduced functionality without systemd, this >should not generally be documented as a (direct or indirect) >Depends or Recommends on systemd-sysv. This is because with such >dependencies, installing such a package can attempt to switch the >init system, which is not the what the user wanted. For example, a >daemon with only a systemd unit file script should still be >installable on a non-systemd system, since it could be started >manually. > >One consequence of this is that on non-systemd systems it may be >possible to install software which will not work, or not work >properly, because of an undeclared dependency on systemd. This is >unfortunate but trying to switch the user's init system is worse. >We hope that better technical approaches can be developed to >address this. > > 6. We recognise that some maintainers find init scripts a burden and >we hope that the community is able to find ways to make it easier >to add support for non-default init systems. Discussions about the >design of such systems should be friendly and cooperative, and if >suitable arrangements are developed they should be supported in the >usual ways within Debian. > > CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED > > 7. Failing to support non-systemd systems when such support is >available, or offered in the form of patches (or packages), >*should* be treated as a release critical bug. For example: init >scripts *must not* be deleted merely because a systemd unit is >provided instead; patches which contribute support for other init >systems (with no substantial effect on systemd installations) >should be filed as bugs with severity `serious'. > >This is intended to provide a lightweight but effective path to >ensuring that reasonable support can be provided to Debian users, >even where the maintainer's priorities lie elsewhere. (Invoking >the Technical Committee about individual patches is not sensible.) > >If the patches are themselves RC-buggy (in the opinion of, >initially, the maintainer, and ultimately the Release Team) then of >course the bug report should be downgraded or closed. > > 8. Maintainers of systemd components, or other gatekeepers (including >
Re: Proposal to overturn init systems premature GR
On Tue, Dec 03, 2019 at 11:34:40PM +0200, Wouter Verhelst wrote: > The issue has existed since five years ago. However, discussion on > *this* GR has started only a month ago. > > A month is fairly short in Debian time to draft all the options on a > ballot that is likely to be so contentions. That we've managed to get > this far is amazing, but does not negate the fact that people are still > working on their draft. > > If this option does not make progress in a few days, then yes, you're > right. But I agree with Ian -- even if I'm unlikely to vote for that > option -- that allowing it a fair chance to arrive onto the ballot is > important. [...] > I don't think that waiting a few more days is going to make the sky > fall. There have been votes that took *far* longer than this one to be > decided on. > > Historically, we've waited until discussion died before we called for > vote. It feels wrong to not do the same now, on an issue that is likely > to be this contentious. I have to somewhat correct my last mail and agree with Wouter here too. Even though the discussion partly has become somewhat painful again, it's important to let people finish drafting their options until they are ready and then vote. Especially after 5 years. Some holiday dates (which affect everyone differently anyway, just like weather) shouldn't influence our voting dates too much. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Proposal to overturn init systems premature GR
On Tue, Dec 03, 2019 at 05:40:57PM +0100, Enrico Zini wrote: > I feel that the air in -vote has been getting very heavy in the last day > or so, and I was quite happy that Sam opted to cut the pain short and go > for a vote. I (mostly) missed this part busy preparing an event... > I agree that all the useful options seem to be on the ballot, and I look > forward to see what comes out. I would prefer that we didn't start > something that looks like meta-discussing options, and meta-discussing > whether to meta-discuss options, and so on. > > Nitpicking on the constitutional process like this looks to me like an > interesting move in some competitive board game. I would prefer to see > less competition, and more cooperative focus on trying to make Policy > unstuck while trying to keep pain to a minimum. _ _ / | _| |_| | |_ _| | |_| |_| (+1) IOW, a GR to overturn the GR to delay the GR about the GR is... then, I also think all the useful options are on the table, but if Ian has something to greatly improve option G, the latest of the available options, very soon, I can see how we can still start voting on the 8th or 10th or 12th or whatever. Everybody who is interested to vote on this GR, and can vote, will know about this GR and so either can vote early and enjoy the holidays or enjoy the holidays, read as much background info as wanted during/after and before the holidays and then vote. (or whenever this vote ends) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Proposal: Focus on systemd
On Fri, Nov 29, 2019 at 10:16:10PM +0200, Martin Michlmayr wrote: > I'd like submit the following proposal: > > Proposal: Focus on systemd to promote standardization and cross-distribution > cooperation > > This resolution is a position statement under section 4.1 (5) of the > Debian constitution: > > Cross-distribution standards and cooperation are important factors in > the choice of core Debian technologies. It is important to recognize > that the Linux ecosystem has widely adopted systemd and that the level > of integration of systemd technologies in Linux systems will increase > with time. > > Debian is proud to support and integrate many different technologies. > With everything we do, the costs and benefits need to be considered, > both for users and in terms of the effects on our development community. > An init system is not an isolated component, but is deeply integrated in > the core layer of the system and affects many packages. We believe that > the benefits of supporting multiple init systems do not outweigh the > costs. > > Debian can continue to provide and explore other init systems, but > systemd is the only officially supported init system. Wishlist bug > reports with patches can be submitted, which package maintainers should > review like other bug reports with patches. As with systemd, work > should be done upstream and in cooperation with other Linux and FOSS > distributions where possible. The priority is on standardization > without the reliance on complicated compatibility layers. > > Integrating systemd more deeply into Debian will lead to a more > integrated and tested system, improve standardization of Linux systems, > and bring many new technologies to our users. Packages can rely upon, > and are encouraged to make full use of, functionality provided by > systemd. Solutions based on systemd technologies will allow for more > cross-distribution cooperation. The project will work on proposals and > coordinate transitions from Debian-specific solutions where appropriate. seconded & thanks. And I'd also like to say that I'd like Debian to stay the harbour for us all. Debian can be bend & expanded in many ways, especially technically. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Review of proposals
On Fri, Nov 29, 2019 at 01:47:18PM +, Ian Jackson wrote: > I was of course speaking metaphorically. I understand, but I think it gets lost. > I note that the very word > "flamewar" which you use yourself has the same problem, at least > etymologically. haha, right, though just etymologically. But we all have different images in mind when we think 'war' and 'flamewar'. At least I hope ;) It certainly was a big bad flamewar :-( > But I'm happy to try to avoid this kind of terminology, for the > reasons you give. So, sorry (and if I do it again please point it out > again). Thanks, very much & no problem. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Review of proposals
On Fri, Nov 29, 2019 at 11:44:55AM +, Ian Jackson wrote: > > For those reasons, I am not sure if I will rank proposal D above FD. I > > would very much prefer if it were compressed to a proposal of about the > > same length as proposals B or C. > I am sorry it is so long, indeed. It's just that I don't see what to > cut. The init systems wars have been so wide-ranging and demonstrated > a large variety of different pathologies, and poor arguments, as well > as of course high-level differences of approach. Ian, could you please stop characterizing those stupid flamewars and mud fights as war? War is something completly different, people die. In my book, speaking of 'init systems wars' is a CoC violation (utterly insulting some) which your very proposal D reminds us not to do. (and btw, I'm very glad that this thread went on so long without mentioning the war. I do think we as community have improved, greatly, and I'm thankful to every individual contributing to this. So I also don't particular mind this offense now.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Review of proposals
On Thu, Nov 28, 2019 at 07:18:37PM +0100, Lucas Nussbaum wrote: > Ordering > > In order to save voters' time by making it possible to read proposals in > a more sensible order, I think they should be re-ordered as: > > Proposal E / Choice 5: Support for multiple init systems is Required > Proposal D / Choice 4: Support non-systemd systems, without blocking progress > Proposal A / Choice 1: Support for multiple init systems is Important > Proposal B / Choice 2: Systemd but we support exploring alternatives > Proposal C / Choice 3: Focus on systemd for init system and other facilities > > (or the reverse, which has the advantage of only permutating between > Sam's proposals, which might be more procedurally acceptable) I wholeheartly support this. (and the rest of what Lucas wrote here, but providing a sensible ordering is the most important bit of it. Thank you very much for this review, Lucas!) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Please wait a bit longer before calling for a vote
On Fri, Nov 29, 2019 at 08:11:48AM -0500, Sam Hartman wrote: [...] > I do not support delaying the CFV for an option that has not gained sponsors. just sigh. Michael, I'm very very likely to sponsor anything you have written so far. Please publish something so it's on the table and Sam cannot argue like he does. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Please drop/replace the use of the term "diversity"
On Wed, Nov 27, 2019 at 07:15:17PM +0100, Kurt Roeckx wrote: > I've updated choice 1 and 5 like that. thank you. > Note that the text of choice 1, 2 and 3 still mention it: > "our current position on Init systems, Init system diversity, and the use of > systemd facilities." how about replacing that with: "our current position on our default Init system, alternative Init system implementations, and the use of systemd facilities." ?!? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
+1 (Re: Please drop/replace the use of the term "diversity")
On Wed, Nov 27, 2019 at 12:54:40PM +0100, Enrico Zini wrote: > > May I gently request we replace the use of the word "diversity" > > throughout the "init systems and systemd" General Resolution prior to > > it being subject to a plebiscite? > Thanks for raising this issue, and yes, please! > > Something like s/init diversity/support for multiple init systems/ > seems to me to address the issue you raise, introduce more clarity, and > it sounds to me also somewhat more precise. For example: this. (thanks & yes!) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Choice Hartmans1a
On Fri, Nov 22, 2019 at 08:01:37AM -0500, Sam Hartman wrote: > I'd appreciate help in achieving these goals without undermining the > text in debref. Choice 1: Init deversity is Important and NMUable -> Choice 1: Init diversity is Important and However, adding an init script to such a package is appropriate for a non-maintainer upload. -> This also means, that according to the NMU guidelines, adding an init script to such a package is appropriate for a non-maintainer upload. ...and non-maintainer uploads to add that support are appropriate. -> ...and non-maintainer uploads following the NMU guidelines to add that support are appropriate. on the text on https://www.debian.org/vote/2019/vote_002#proposera with Last Modified: Thu, Nov 21 17:08:51 UTC 2019 Last Built: Thu, Nov 2117:09:59 UTC 2019 -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Should I withdraw choice hartmans1?
On Fri, Nov 22, 2019 at 01:32:35AM +, Dmitry Bogatov wrote: > [ I read version of hartman1, which is based on my draft with s/must/should/] > > I do not think your option actually adds value, and not aware of > somebody, who prefers your option to either Ian's or mine. On other > hand our system is resistant to multiple close options, so the only loss > is that every voter will have to thorously read one more text. I disagree and very much think that it's useful to have hartman1 as an option. 'should' or 'must' makes a whole lot of difference. (I do however also agree with gregoa's comments on the NMU part of this: 'Inventing NMUability rules tied to bug severities in a GR seems counterproductive to me.' and 'This contradicts the spirit, culture, and conventions around NMUs which are prevalent in Debian for at least ten years and are written down in DevRef 5.11.1.'.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Proposal: General Resolution on Init Systems and systemd Facilities
On Wed, Nov 20, 2019 at 09:37:59PM +, Holger Levsen wrote: > ah! Now I see that this is ment differently than it was proposed. s#it#how I understood it# -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Proposal: General Resolution on Init Systems and systemd Facilities
On Tue, Nov 19, 2019 at 01:24:24PM -0800, Russ Allbery wrote: > > I agree with Holger that it's probably better to leave the amount of > > time undefined, and see what happens on a case by case basis. > If we're going to expect there to be a transition period, I would prefer > the time be defined, rather than left for case-by-case argument. If folks > would prefer that we have zero delay (as soon as Policy standardizes a > facility currently only supported by systemd, people can start using it > immediately), that's viable from a Policy perspective. But it's hard (and > not particularly fun) work on Policy to decide a reasonable non-zero delay > on a case-by-case basis for every feature. ah! Now I see that this is ment differently than it was proposed. Me blames the length of the third sentence in paragraph #9 in proposal D on https://www.debian.org/vote/2019/vote_002 What I missed that this delay (of 6/12 month) is a delay for *-policy* about describing/defining such a feature. I thought it ment to prohibit people from using such new features. Of course policy can lag behind 'artificially' (or on purpose), I mean, fine, as long as new software can be uploaded and make use of such features. (I really wouldnt want it to become impossible to just upload the latest gnome release.) > Ian's text says that we always introduce new feature descriptions and then > pick something between six months and a year before people get to start > using the new thing, and provides an easy out that in the case of > disagreement we can just always pick a year and be done. In practice you can and do this already. (By saying, this is too new, policy describes status quo, etc). > This may slow progress, but it removes a point of argument, which is very > appealing. I wonder why you dont prefer a fixed timeline then. 6 *or* 12 months. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Proposal: General Resolution on Init Systems and systemd Facilities
On Sat, Nov 16, 2019 at 06:12:49PM +, Ian Jackson wrote:
> Holger Levsen writes ("Re: Proposal: General Resolution on Init Systems and
> systemd Facilities"):
> > On Fri, Nov 15, 2019 at 01:22:26PM -0700, Sean Whitton wrote:
> > > If we found that the six month delay was repeatedly expiring with no
> > > serious attempts at non-systemd implementations of the new features, we
> > > could repeal this GR.
> > I'm pondering an amendment to copy this option but without the 6 month
> > delay clause.
> In practice, we (in Debian as a whole) generally delay things for much
> longer than that, in order to give people a chance to catch up.
I'd also say, because delays just happen, even though we have many
people updating software timely in unstable regularily, we also have
regularily delays. I don't think we should add more artifical delays.
Also, your GR text is unclear when those 6 or 12 months start.
And then, let's says systemd and gnome together develop a feature which
is then used by gnome, does that mean that also the gnome maintainers
cannot upload new versions of gnome?
> If you just delete the bit about the delay, what will you replace it
> with ? If you say 0 delay then it amounts to standardising and
> recommending in policy a change which actually makes programs buggy as
> soon as you apply it.
I'd replace:
[...] The
transition should be smooth for all users. The non-systemd
community should be given at least 6 months, preferably at least 12
months, to develop their implementation. (The same goes for any
future enhancements.)
with
[...] The
transition should be as smooth as possible for all users including
those of alternative init systems.
> In other words: is it really not worth waiting a very short time in
> Debian terms (1/4 of a release cycle)
this delay might well cause further delays to the release cycle, thus
making the release cycle longer (and thus the impact even smaller, one
could say... ;)
> FTAOD of course what you propose is up to you.
thanks! and, somewhat btw, many thanks for your stated goal of shifting
these, aehm, issues from fights to bugs. Very much appreciated (and quite
successful, I think.)
I'm trying to do the same. I'm really not sure I could rank this proposal
above NOTA with the delay clause, while without I think I could very well.
--
cheers,
Holger
---
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
signature.asc
Description: PGP signature
Re: Proposal: General Resolution on Init Systems and systemd Facilities
On Fri, Nov 15, 2019 at 01:22:26PM -0700, Sean Whitton wrote: > If we found that the six month delay was repeatedly expiring with no > serious attempts at non-systemd implementations of the new features, we > could repeal this GR. I'm pondering an amendment to copy this option but without the 6 month delay clause. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
adding more topics to this GR (Re: [draft] Draft text on Init Systems GR)
On Thu, Nov 14, 2019 at 05:31:19PM +, Ian Jackson wrote: > Issue 4. Hateful stuff on our lists etc. > > I have tried to capture what kinds of statements are the key problem > here. I think we need to clearly tell our listmasters etc. what we > expect, since enforcement action they take needs clear legitimacy. I very well see how this is something we ought to address (at some time, maybe even now), but I'm really not convinced (over-)loading the already overloaded init system GR with listmaster policying stuff is wise. *Please* reconsider. (and please excuse my brevity.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Matthias's Choice 4
On Wed, Nov 13, 2019 at 04:19:29PM +0100, Matthias Klumpp wrote: > I think there are only two differences: [...] there's a third, the title. > However, I think it may be useful to highlight in the vote text > somewhere that systemd is actually not just the init system, but a > modular collection of different tools designed to work well together > (many, but not all of them depending on systemd being PID 1), and that > there may be benefit to the Debian operating system in deciding to > adopt some of them, at least on the Linux ports. It's also worth > noting that upstream projects may assume some of the facilities to be > present on systems, and may make the distributor write the integration > glue for non-systemd systems themselves if they don't want to support > a configuration they don't run and test upstream. This makes package > maintenance harder without commitment to some systemd stuff. I agree. regarding Matthias' text, I noticed there should be another sentence in it: it's ok to close those 'please supply an initscript' bugs as wontfix. (ok, but not recommended.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
On Wed, Nov 13, 2019 at 02:59:51PM +0100, Matthias Klumpp wrote: > Exactly this. I think I would definitely second a "focus on systemd" > amendment which makes packages support systemd as a priority, but > doesn't force out sysvinit or any other init system from the archive. > I think there's a valid point in having them, and as long as they > don't impair the default init system and people aren't forced to do > work they can't test, it's fine to have them. indeed. > So, something like this maybe? (adapted from Alexander E. Patrakov's text): > ``` > Choice 4: Focus on systemd as init system and features requiring it > > The Debian project recognizes that systemd service units are nowadays > the preferred configuration for describing how to start a daemon/service. > Packages should include service units. At the same time, > the Debian project acknowledges that maintainers and upstream developers > are often unable to provide high-quality (or any) support for alternative > init systems in their packages on their own and can not or do not test > that their > packages work under such init systems. It is not realistic to expect > the situation to improve, and Debian does not want to block > experimentation with new Linux-based technologies developed under the > systemd project umbrella or hinder their adoption by requiring all > other init systems to support the same features as well (which may not > even be desired by those projects). > Therefore, Debian should focus on a polished experience with systemd > as init system as first priority. Other init systems will remain > available as long as there is enough interest by people to maintain > them. Package maintainers are encouraged to accept patches to support > non-systemd configurations, as long as the changes do not impair the > user experience when systemd is available. Package maintainers may > split out support for alternative init systems into separate binary > packages. Maintainers of other init systems are encouraged to test > support for their configurations if the package maintainer can not do > it. > > Debian is still committed to working with derivatives that make > different choices about init systems. > ``` > This would mean that it's not a bug if no sysvinit script is provided > by a package and only a systemd unit is available. Also, if a sysvinit > script is faulty, such an issue would be a normal/important bug and > wouldn't get a package removed or excluded from release. At the same > time, maintainers of alternative init systems could add support for > their systems, as long as they test it (CI/autopkgtest may help > there). > Any alternative init system would very much be second-class, but so > are alternative kernels, or compilers, or libc implementations, or > architectures (or desktop environments, some would argue), and that > doesn't stop people from doing awesome work on them. And if we ever > want to switch away from systemd to something else, we still could - > but until then, the experience with it should be as good as we can > possibly make it. > > This is not a finished proposal, but something I would be much more > likely get behind compared to a "systemd and completely screw > everybody who wants something else by policy" approach. many thanks for writing this up. I'd second such an amendment. With two small changes: - s#This would mean that it's not a bug if no sysvinit script is \ provided#This would mean that it's not an important (or higher) \ bug if no sysvinit script is provided# - s#normal/important bug#norma bug# -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
On Tue, Nov 12, 2019 at 09:51:03PM +0500, Alexander E. Patrakov wrote: > Choice 4: systemd without Diversity at all as said before, I dislike the 'without diversity' framing and think it's wrong, misleading and insulting. So I'd rather propose 'focus our efforts on systemd' or 'systemd and overcoming technical debt' or whatever. systems running systemd vary a lot and have a *lot* diversity. similarily I would also *not* call sysv bad names or frame it badly. (and maybe even calling it 'technical debt' is not a good idea.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Init Systems GR Timeline
On Fri, Nov 08, 2019 at 06:46:53PM -0500, Sam Hartman wrote: > I think you may be mishearing what I'm proposing for a timeline. [...] thanks for clarifying, Sam, much appreciated. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: [draft] Draft text on Init Systems GR
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: > > version 2330c05afa4 > Choice 1: Affirm Init Diversity [...] looks generally like a fine option to me. > Choice 2: systemd but we Support Exploring Alternatives [...] as others have said, this mixes init systems with systemd-logind. > Choice 3: systemd without Diversity as a Priority [...] I guess this option will get ammendments: a.) 'systemd without diversity as a priority' sounds like systemd is against diversity. I think this is borderline insulting. So I expect this will attract someone proposing another option called 'Embrace the future (*) and a modern init system' or such. *) or 'Embrace new technologies...' b.) I guess some will want something like this option on the ballot but without the commitment about working with downstreams _worded this way_. c.) Some will not want 'Packages should include service units or init scripts to start daemons and services' but rather a much stronger recommendation to drop init scripts and ship unit files. On top of all of this, systemd provides much more features than unit files as the thread on -devel showed. There is no word about these technologies in this GR proposal. I think that's a flaw in this proposal. Then, I think the ballot also misses an option for the sysv-lovers, 'Embrace systems without systemd' or some such, which explicitly forbids using systemd technology without alternative support working on sysv systems. I think it would be very useful to know whether 0.5, 5%, or 15% or 25% (or more?) of our developers think such would be a good choice. Finally, I don't think it's a good idea to rush this to a vote in 7 days. I'm tempted to mail d-d-a to make people who are not regularily read -vote aware of this discussion. (There are also many people who don't read -devel.) Sam, I'd appreciate if I wouldn't need to do that, because you sent such a short pointer to -vote on d-d-a *before* calling for a vote. Like now. Last, and definitly not least: many thanks for working on this, Sam. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
why mention Constitution section 4.1 (5 or even 4)? (Re: [draft] Draft text on Init Systems GR)
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: > > version 2330c05afa4 > > Using its power under Constitution section 4.1 (5) I fail to see why Constitution section 4.1 (5) is referred here. I'd better understand section 4.1 (4) and would probably would prefer to leave out this half sentence completly. (I'll comment on other aspects seperately if I have more comments.) Thanks. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: First Debian community-wide IRC sessions scheduled: Meet the new DPL and ask him anything!
On Mon, Apr 22, 2019 at 09:57:36AM +0200, Jonathan Carter wrote: > Yep, meetbot is there and publicity team will publish it to bits between > 3-5 May and then again closer to the time again on micronews. nice. signature.asc Description: PGP signature
Re: First Debian community-wide IRC sessions scheduled: Meet the new DPL and ask him anything!
On Sun, Apr 21, 2019 at 04:09:12PM +0200, Jonathan Carter wrote: > As you probably know by now, Sam Hartman won the election and is now our > new DPL (congratulations!). congrats to Sam indeed. And thanks to all four who have been running! > The first of these is re-booting the #debian-meeting irc channel > (https://wiki.debian.org/IRC/debian-meeting) and schedule general > community meetings there. thanks for this initiative! I think it's a nice one! two comments: will you use meetbot(.debian.net) to provide logs etc? and maybe you want to annonce this somewhere else than -vote@ too. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2019: Call for nominations
On Tue, Mar 12, 2019 at 07:46:19AM -0600, Bdale Garbee wrote: > Chris, thank you for your service! Two terms as DPL is a serious > contribution > and commitment to Debian, and I greatly appreciate it! indeed. Chris, many thanks for all your DPL work in the last two years. IMO you were truely amazing, effective and inspiring, especially the transparency! Also, thanks for stating clearly you won't run again. And as such also kudos and thanks to those daring to run this year ;) -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Q to Mehdi: safe and fun
On Tue, Apr 11, 2017 at 01:02:57AM +0100, Martín Ferrari wrote: > After waiting for two months we were informed by Mehdi that as > first-step solution, he had asked this person to "stay away from > Debconf17" (which had started being prepared almost a year before). This > person supposedly agreed to stay away, but he continued being visibly > active to this day. yup, the dpl asked kindly and the DD didnt comply. > All this seems to me like a typical case of victim-blaming and > protecting the harasser. And that is why I bring all this noise to the list. kudos for your energy. -- cheers, Holger signature.asc Description: Digital signature
Re: Q to Mehdi: safe and fun
On Sat, Apr 01, 2017 at 11:52:51PM +0200, Mehdi Dogguy wrote: > On 31/03/2017 12:38, Holger Levsen wrote: > > On Fri, Mar 31, 2017 at 04:00:49AM +0200, Mehdi Dogguy wrote: > >> If you want to ban someone from a mailing list, you may contact > >> list-masters. > >> If you want to ban someone from IRC, you may contact IRC operators. > >> if you want to ben someone from the project, you may contact DAM. > >> If you contact the DPL, then you're asking for some mediation. > > > > I must say I'm disappointed by this response in the context of debconf-team… > Can you please clarify what you find disappointing and why here? in the case "of debconf-team", I dont think banning $that person from the lists or from irc would be appropriate (one can be very very annoying and yet not violating any rules) and offering mediation by the DPL *now*, after several people left or severely reduced their involvement, is also way too late. hope that clarifies. > > Banning someone is a last step, what's lacking are steps before that. > > > > Granted mediation *is* a step before banning, but IMO it didnt work well in > > the context of debconf-team… though "didnt work well" is a very mild way to > > put it :-( > > > > Also, I think mediation was tried way too late (=years), after several team > > members burned out, left and were not interested in mediation anymore. > > > > (Sadly I have not much constructive to say here right now…) > > > > > -- cheers, Holger signature.asc Description: Digital signature
Re: having public irc logs?
On Thu, Apr 06, 2017 at 08:44:20AM +, Gianfranco Costamagna wrote: > Debian has a "we don't hide things" wording in his constitution. I think you are misremembering. "We dont hide problems and we promise that we will operate our bug tracking system in public forever". And that's from the social contract (#3 of it), not the constitution. Debian never said we would make everything public. -- cheers, Holger signature.asc Description: Digital signature
