Re: [RFC] General Resolution to deploy tag2upload
* Russ Allbery [2024-06-16 09:02]: I believe that's what tag2upload pushes to the dgit-repos server, although I'm not sure that exactly matches what you're asking for. I was pondering over a way to securely link the Git tag with the upload. I think it needs to be a representable as a file that can be signed and uploaded together with the source package; this enables dak (or anyone else for that matter) to verify that the Git tag corresponds to the upload and simultaneously serves as an audit trail for whatever t2u deemed necessary to do. A Git patch might fit the bill, it depends whether you consider it sufficient to compare the (extracted) source trees or if you want to be able to reconstruct a bit-identical copy of the source package tarballs. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: [RFC] General Resolution to deploy tag2upload
Hi Russ, * Russ Allbery [2024-06-15 23:57]: Scott Kitterman writes: Today I can download any source package in the archive and verify who uploaded the package and is responsible for its contents. It doesn't matter if I download it from the main archive or a mirror. Personally, I think that's an important characteristic of our package archive, which is lost by tag2upload. The same *information* is there, provided that the tag2upload metadata is trustworthy, but it is not trivial to verify that tag2upload did its part of the job properly. You can trace the package back to tag2upload and you can see who tag2upload asserted uploaded the package, and you can then retrieve that signed Git tag and verify it, but in order to establish the last missing link, you would have to redo the work that tag2upload did to assemble the source package to check that it was done properly. Would it be possible for tag2upload generate some sort of log or diff of its operation? Then, a verifier does not have to reimplement the whole dgit logic with all its edge cases, it merely has to apply the same tree transformation(s) as t2u and verify that this will indeed produce the source package from the signed Git tag. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: [RFC] General Resolution to deploy tag2upload
Hi, * Luca Boccassi [2024-06-13 14:51]: I was not, I wasn't suggesting to make this a hard requirement, as you say that's more complicated. Merely moving the fire-and-forget webhook as the last stage of the pipeline, as the default setting/setup/config/whatever. This is not to provide strong guarantees, but merely an easy default that encourages a QA pass first. Then maintainers can override the pipeline config and skip it, if they don't want it for any reason. If it was the default, I suspect de-facto the majority of uploads would go through it, and we would gain in quality, on average (exceptions apply, etc etc). Sure, having the option and even having the option as default is perfectly fine. If I can instruct tag2upload not to wait for the CI on certain uploads, I might even leave it on ;) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: [RFC] General Resolution to deploy tag2upload
Hi, * Luca Boccassi [2024-06-13 14:23]: As far as I understand in the current proposal the trigger is a webhook running on Salsa after a push - have you considered instead having the trigger be a stage in the salsa-ci pipeline, that would run after the previous stages have completed successfully? I hate that idea. From past experience, the Salsa CI pipeline is slower and much more flaky than the buildds, so I'm not going to spend several hours (and retries) per upload waiting to see if the Salsa CI deemed my upload worthy. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: [RFC] General Resolution to deploy tag2upload
Hello Sean, first of all, I have been a very happy user of dgit for some time now, and I want to use the opportunity to thank Ian and you for your excellent work. I consider dgit to be one of two major improvements to my packaging workflow (the other being sbuild with unshare backend), and I have no doubt that tag2upload will be just as reliable and useful. * Sean Whitton [2024-06-12 06:25]: = BEGIN FORMAL RESOLUTION TEXT tag2upload allows DDs and DMs to upload simply by using the git-debpush(1) script to push a signed git tag. 1. tag2upload, in the form designed and implemented by Sean Whitton and Ian Jackson, and reviewed by Jonathan McDowell and Russ Allbery, should be deployed to official Debian infrastructure. Considering that tag2upload is supposed to become a critical component of our infrastructure, I am missing (or may have overlooked) some information on how the deployment is going to be maintained. I assume that you will continue to work on the code itself, but who is going to be responsible for keeping the tag2upload service operational? Are you going to manage the deployment as well, has DSA agreed to do it, or do you have an altogether different arrangement in mind? Again, thank you your for work on this! Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: On community and conflicts
* Joerg Jaspert [2023-03-16 16:20]: This seems to come from a point of view that any "wrong thing one may write leads to an exclusion". And that's just so wrong, that even trying to define something here is impossible - and also wrong. That point of view has been insinuated and rebutted often enough that it might qualify for a Debian extension to Godwin's law. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: new proposal: free and and non-free installers with SC change
* Holger Levsen [2022-09-14 15:00]: hi, I'm looking seconds for this new proposal below, which is like proposal E plus *also* offering free installer image. Rationale: we should keep producing fully freely distributable Debian installer images, for those cases were some included non-free stuff else might limit distribution, eg to Iran or Cuba etc or by imposing other restrictions...! - Proposal F This ballot option supersedes the Debian Social Contract (a foundation document) under point 4.1.5 of the constitution and thus requires a 3:1 majority. The Debian Social Contract is replaced with a new version that is identical to the current version in all respects except that it adds the following sentence to the end of point 5: The Debian official media may include firmware that is otherwise not part of the Debian system to enable use of Debian with hardware that requires such firmware. The Debian Project also makes the following statement on an issue of the day: We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.). When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. Where non-free firmware is found to be necessary, the target system will also be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software. We will publish these images as official Debian media, alongside the current media sets that do not include non-free firmware packages. --- (This is exactly "Proposal E" as found on https://www.debian.org/vote/2022/vote_003 now, except that in the very last sentence the word "replacing" has been replaced with "alongside".) Seconded. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Changing how we handle non-free firmware
* Steve McIntyre <93...@debian.org> [2022-08-18 20:58]: Hi a11! I'm proposing to change how we handle non-free firmware in Debian. I've written about this a few times already this year [1, 2] and I ran a session on the subject at DebConf [3]. TL;DR: The way we deal with (non-free) firmware in Debian isn't great. For a long time we've got away without supporting and including (non-free) firmware on Debian systems. We don't *want* to have to provide (non-free) firmware to our users, and in an ideal world we wouldn't need to. However, it's no longer a sensible path when trying to support lots of common current hardware. Increasingly, modern computers don't function fully without these firmware blobs. Since I started talking about this, Ansgar has already added dak support for a new, separate non-free-firmware component - see [4]. This makes part of my original proposal moot! More work is needed yet to make use of this support, but it's started! :-) I believe that there is reasonably wide support for changing what we do with non-free firmware. I see several possible paths forward, but as I've stated previously I don't want to be making the decision alone. I believe that the Debian project as a whole needs to make the decision on which path is the correct one. I'm *not* going to propose full text for all the possible choices here; as eloquently suggested by Russ [5], it's probably better to leave it for other people to come up with the text of options that they feel should also be on the ballot. So, I propose the following: = We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will *normally* be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.). When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. The target system will *also* be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software. We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages. = A reason for defaulting to installing non-free firmware *by default* is accessibility. A blind user running the installer in text-to-speech mode may need audio firmware loaded to be able to drive the installer at all. It's going to be very difficult for them to change this. Other people should be able to drive the system (boot menus, etc.) to *not* install the non-free firmware packages if desired. We will *only* include the non-free-firmware component on our media and on installed systems by default. As a general policy, we still do not want to see other non-free software in use. Users may still enable the existing non-free component if they need it. We also need to do the work to make this happen: * in d-i, live-boot and elsewhere to make information about firmware available. * add support for the non-free-firmware section in more places: ftpsync, debian-cd and more. and I plan to start on some of those soon. [1] https://blog.einval.com/2022/04/19#firmware-what-do-we-do [2] https://lists.debian.org/debian-devel/2022/04/msg00130.html [3] https://debconf22.debconf.org/talks/43-fixing-the-firmware-mess/ [4] https://incoming.debian.org/debian-buildd/dists/buildd-unstable [5] https://lists.debian.org/debian-devel/2022/04/msg00214.html -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... Seconded. -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Results for Voting secrecy
* Christian Kastner [2022-03-28 07:54]: The latter explicitly reaffirms the status quo, the former does not. I guess this is why Holger proposed Choice 3. Yes, and this is exactly how I used Option 3 to express my preference. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: GR Ballot Option: Allow, but do not require, secret voting
* Harlan Lieberman-Berg [2022-03-05 16:13]: I hereby amend this proposal, unless any of the seconding Developers (CCed) objects. The diff follows: commit 7c4d89528a50345b0bd0e67d9d36499413d9d6c1 Author: Harlan Lieberman-Berg Date: Sat Mar 5 16:01:26 2022 -0500 Change language as suggested by rlaager diff --git a/english/devel/constitution.wml b/english/devel/constitution.wml index 7924992d3a7..4830c972df9 100644 --- a/english/devel/constitution.wml +++ b/english/devel/constitution.wml @@ -225,16 +225,10 @@ earlier can overrule everyone listed later. - - Votes, tallies, and results are not revealed during the voting period. - After the vote, the Project Secretary lists all the votes cast, unless - either one of the following is true: - - - The vote is for a leadership election as defined in 5.2. - At least 4K Developers have sponsored any single ballot option - which says the votes will be kept secret. - +Votes, tallies, and results are not revealed during the voting period. +If, during the discussion period, at least 4K Developers call for a secret +ballot, then the votes are kept secret. Otherwise, after the vote, the +Project Secretary lists all the votes cast. @@ -854,12 +848,12 @@ plebiscites, where stated above. proposed disagree with that change within 24 hours. If any of them do disagree, the ballot option is left unchanged. - The addition of a ballot option or the change via an amendment of a - ballot option changes the end of the discussion period to be one week - from when that action was done, unless that would make the total - discussion period shorter than the minimum discussion period or longer - than the maximum discussion period. In the latter case, the length of - the discussion period is instead set to the maximum discussion + The addition of a ballot option, the change via an amendment of a ballot + option, or a successful call for a secret ballot changes the end of the + discussion period to be one week from when that action was done, unless that + would make the total discussion period shorter than the minimum discussion + period or longer than the maximum discussion period. In the latter case, the + length of the discussion period is instead set to the maximum discussion period. The proposer of a ballot option may make minor changes to that I sponsor this ballot option in its amended form. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Reaffirm public voting
* Russ Allbery [2022-03-05 12:39]: I'm not sure that I see this for DPL elections because we publish both the list of votes and the list of voters. If those two lists aren't the same length, that's fairly trivially detectable. You're right, I missed that when I looked at the election results. In that case, the forger needs to map some voters who voted identically to the same HMAC_SHA256_HEX value, which means you need to find collisions on the HMAC keys such that H(uid1, K1) == H(uid2, K2) I don't know how resistant HMAC-SHA256 is to this type of "chosen key" attack. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Reaffirm public voting
* Thomas Goirand : 1- vote-privacy: the fact that a particular voter voted in a particular way is not revealed to anyone. 2- Receipt-freeness: a voter does not gain any information (a receipt) which can be used to prove to a coercer that she voted in a certain way. 3- Coercion-resistance: a voter cannot cooperate with a coercer to prove to him that she voted in a certain way. 4- Individual verifiability: a voter can check that her own ballot is included in the election's bulletin board. 5- Universal verifiability: anyone can check that the election outcome corresponds to the ballots published on the bulletin board. 6- Eligibility verifiability: anyone can check that each vote in the election outcome was cast by a registered voter and there is at most one vote per voter. * Russ Allbery : I'm personally more interested in using something like Belenios than just replicating the DPL election scheme mostly because I'm unsure that the DPL election scheme has had sufficient security analysis and I'd prefer to see us move onto the firmer footing of a voting system that's had a published rigorous analysis of its properties and I'm not aware of one for our current DPL election system. (I would love to be corrected if one does exist.) That analysis is quickly done: Property 1 holds contigent on the security of HMAC-SHA256 and discounting side channel attacks on the voting server itself. [Technically, it's violated because the secretary can see all votes, but I don't think that is a problem in our use-case.] Property 2 is violated if the vote is confirmed in a signed email like the public votes (I can't say because I never participated in a DPL election yet). Property 3 is violated because the HMAC key can be passed on. Property 4 holds, as does property 5, because all ballots are published with the corresponding HMAC_SHA256_HEX values. Property 6 is violated, because you can trivially add arbitrary ballots with random HMAC_SHA256_HEX values (unless the voter turnout is 100%, which seems rather unlikely). I'm also in favor of using a Belenios derivative, especially since Stephane already agreed to help us adopt the system for Debian. We can probably even reduce the complexity a bit because we can live with a weakened form of property 1 (that is, the secretary may learn the voting behavior of individual DDs). Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Secret Ballots: How Secret
Hi Sam, * Sam Hartman [2022-02-17 16:14]: Would you prefer that we not mandate that voters be able to verify their votes were counted so that we could have plausibel deniability? Are there aspects of DPL elections that make this less of an issue for DPL elections than other issues? The way I see it, we have two goals to define: 1. Level of secrecy. Is it enough if Non-DDs cannot look up my vote on the Internet, or should my vote remain so secret that I can't even prove to someone else that I voted at all? 2. Ease of verification. Should it be possible to audit the results with some basic counting abilities (and maybe access to the Wikipedia page on the Schulze method), or is it acceptable if the verification is so involved that it cannot be done without software assistance and/or extensive expertise? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: GR: Change the resolution process (2021-11-25 revision)
* Pierre-Elliott Bécue [2021-11-26 09:49]: Seconded. I was under the impression that this amendment by the original proposer does not require re-sponsoring, and my consent is implicitly assumed unless I choose to object. Am I wrong? (If I am, consider this my sponsoring of the amended version) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: GR: Change the resolution process (corrected)
efault option are withdrawn, the resolution is canceled and will not be voted on. A.3. Calling for a vote 1. After the discussion period has ended, the Project Secretary will publish the ballot and call for a vote. The Project Secretary may do this immediately following the end of the discussion period and must do so within five days of the end of the discussion period. 2. The Project Secretary determines the order of ballot options. At their discretion they may reword the single-line summaries for clarity. 3. Minor changes to ballot options under point A.1.5 may not be made after or within 24 hours of the end of the discussion period unless the Project Secretary agrees the change does not alter the meaning of the ballot option and (if it would do so) warrants delaying the vote. The Project Secretary will allow 24 hours for objections after any such change before issuing the call for a vote. 4. No new ballot options may be proposed, no ballot options may be amended, and no proposers or sponsors may withdraw within 24 hours of the end of the discussion period unless this action successfully extends the discussion period under point A.1.4 by at least 24 additional hours. 5. Actions to preserve the existing ballot may be taken within 24 hours of the end of the discussion period, namely a sponsor objecting to an amendment under point A.1.3, a Developer objecting to a minor change under point A.1.5, stepping forward as the proposer for an existing ballot option whose original proposer has withdrawn it under point A.2.1, or sponsoring an existing ballot option that has fewer than the required number of sponsors because of the withdrawal of a sponsor under point A.2.2. 6. The Project Secretary may make an exception to point A.3.4 and accept changes to the ballot after they are no longer allowed, provided that this is done at least 24 hours prior to the issuance of a call for a vote. All other requirements for making a change to the ballot must still be met. This is expected to be rare and should only be done if the Project Secretary believes it would be harmful to the best interests of the project for the change to not be made. A.4. Voting procedure 1. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement. The default option does not have any supermajority requirements. 2. The votes are counted according to the rules in section §A.5. 3. In cases of doubt the Project Secretary shall decide on matters of procedure. Strike section A.5 in its entirety. Rename section A.6 to A.5. Replace the paragraph at the end of section A.6 (now A.5) with: When the vote counting mechanism of the Standard Resolution Procedure is to be used, the text which refers to it must specify who has a casting vote, the quorum, the default option, and any supermajority requirement. The default option must not have any supermajority requirements. Seconded. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Draft GR for resolution process changes
* Russ Allbery [2021-11-11 08:26]: Once a proposal has been sponsored and added to the ballot, we, as a general social convention, stop sponsoring it unless it feels particularly important to be listed as a sponsor. That means that any given option currently on the ballot usually has "hidden" support in the form of Developers who intend to vote for it but haven't sponsored it. It seems likely that in some situations those Developers may think "okay, the opinion I really cared about is on the ballot so I can vote the way I want" and then may tune out the subsequent discussion. In other words, I think once a ballot option makes it onto the ballot, the rules are attempting to capture the sense that it no longer belongs just to its proposer, but now represents some unknown number of people who want to vote for it. Given that, if the proposer changes their mind and wants to propose a substantially different ballot option, I think the default should be that the proposer do that as a separate ballot option and get sponsors for that new ballot option (and possibly withdraw as the proposer for the original ballot option). This reflects the fact that just because the proposer changed their mind, that doesn't mean that other supporters of that ballot option also changed their minds. As Sam says, the ability to make substantive changes if all sponsors agree is essentially an optimization. It's tedious to propose a new option, have everyone sponsor it again, withdraw as proposer of the old option, and confirm that no one else is stepping forward, so for changes that everyone agrees make the ballot option better, we should have a way to allow those to be made more easily. But we want some sort of check that this is really true and not just take the proposer's word for it, so we in essence draft the sponsors of the ballot option as referees to decide whether this change does make sense in the context in which they originally supported that option. I must say I find your reasoning convincing. A certain stability of ballot options is desirable, and as our voting scheme does not suffer from spoiler effects, we can afford to keep the odd stale option. Besides, as you pointed out, the original proposer can always formally withdraw and ask their sponsors to do the same; if there is hidden support, it will either materialize or the option will be discarded; no additional procedural rules required. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Draft GR for resolution process changes
* Russ Allbery [2021-11-08 08:18]: Probably the simplest fix would be to add something like this as a new point A.0.3. Do people think it would be worth adding something like this? If a proposal (or ballot option; see section §A.1) requires some number of sponsors N, only the first N Developers indicating they sponsor the proposal become sponsors for the purposes of the subsequent process. Further sponsorships are not counted. Similarly, if more sponsors are needed (such as in cases of withdrawal; see section §A.2), only the number of Developers required to meet the minimum number of sponsors are added as sponsors. The Project Secretary determines the order in which sponsors indicate support. (I'm really not happy with the wording of that, and am finding it difficult to word clearly for some reason. Suggestions welcome, if folks think this is something the proposal should try to address.) Given that any Developer can propose a new ballot option anyway, it feels overly restrictive that a single dissenting voice can block amendments. Instead, I'd like to treat this more like a fork; anyone objecting to a change is free to introduce the original version as their own ballot option, subject to the usual sponsorship requirements. In practise, this should work like this: 1. The proposer amends their ballot option. 2. If no sponsor objects to the change, we are done. Otherwise, continue. 3. If someone objects, the proposer decides if he wants to revert the amendment. If yes, we are done. Otherwise, continue. 4. The first objector becomes new proposer for the original ballot option, and the original proposer becomes proposer for the amended version. 5. Any Developer can sponsor or withdraw from both versions as they see fit. By default, i.e. if no other statement is issued, any sponsor who objected to the amendment is assumed to have withdrawn from the amended version and still sponsoring the old version. All other sponsors are assumed to have withdrawn from the old version and are sponsoring the amended version. 6. Any version that lacks the required number of sponsors will be withdrawn. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Renaming the FTP Masters
Hi Felix, * Felix Lechner [2021-11-03 14:27]: I would like to rename the FTP Masters team—ideally via a General Resolution. [...] PROPOSED TEXT In recognizance of the awful history of slavery, the Debian project will rename the "FTP Masters" team. For a long time, the word "master" has been associated with the grave injustices of slavery. [1] While there is a tradition in computing to label primary equipment as a "master" and replicated equipment as "slaves" [2] the use of the word "masters" for a group of people with special privileges [3] shocks the conscience. Within that context, the team's use of the title "wizard" [4] was also problematic. The Ku Klux Klan and its spinoffs used the title "wizard" to style high officials. [5] The team will likewise discontinue the use of the term "wizard" to designate any current or former members. Nothing in this resolution shall impair the continued use of the "master/slave" analogy for technical equipment. "Without a struggle, there can be no progress." (Frederick Douglass) [1] https://en.wikipedia.org/wiki/History_of_slavery [2] https://en.wikipedia.org/wiki/Master/slave_(technology) [3] "The FTP masters can do everything in the archive.", https://wiki.debian.org/Teams/FTPMaster [4] "The FTP Wizard role consists of former team members", https://ftp-master.debian.org/ [5] https://en.wikipedia.org/wiki/Grand_Wizard I'm not going to repeat Karsten's arguments; I agree with him that our usage of master is not associated with slavery in such a way that we absolutely need to abandon the word. Neither is wizard (unless anyone insists on "Grand Wizard" as title). While I also agree with Paul that the current name is somewhat dated technologically, it is not fatally flawed. Therefore, I think we should leave the naming decision to the FTP masters themselves. I am fine with any name on which the FTP masters and the DPL can agree, including the current one. I would also happily ratify their choice via GR if they felt that the whole project should have a say. What I do not want is force a GR decision upon them. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Draft proposal for resolution process change (v2)
Hi Russ, * Russ Allbery [2021-10-05 21:16]: I'm somewhat surprised that there has been no discussion of the timing of the GR discussion period, which I expected to be more controversial. The scheme I'm proposing is relatively complex but allows the discussion period to vary from 1 week to 4 weeks based on how much ballot option activity there is and based on DPL actions. If anyone is unhappy with that (if, for example, you think it's too complex or 4 weeks is too short or too long), now would be a good time to bring that up so that we can discuss it. Thank you very much for the reminder, and allow me to add my two cents: The Debian Constitution, like most good constitutions, has this nice power hierarchy: at the lower end of the spectrum, a single maintainer can act quickly as they see fit, but with limited scope and subject to the Constitution and the Policy. (The DPL is not unlike a maintainer for the debian-project package in this regard). At the upper end, the assembly of all developers has basically unlimited powers via GR, but requires exensive deliberations and a certain amount of time to decide. The Tech-CTTE is somewhere in the middle. In a sense, the GR is the Ultimate Weapon for large-scale decisions beyond the scope of a single maintainer, a group of maintainers, or any other constitutional entity. As such, I regard a certain cumbersomeness as a feature, not a bug. I believe it is more important to have a well-understood, very predictable process that ensures all voices are heard, even if it sacrifices flexibility. We already have the DPL and other delegated teams to deal with more urgent issues. I'd prefer a fixed N week discussion period for some reasonable N over any scheme that depends on DD oder DPL actions and may easily become subject to rule gaming. At the most, I would add a provision to extend the discussion period under certain circumstances if N is relatively small. This way, any DD can anticipate the voting period well in advance and adjust their personal schedule accordingly to make sure they can vote if the issue is important to them. And if we identify any topic that requires more urgent decisions on a regular basis, I think the GR should not become a micro management tool but delegate the necessary power the DPL or some other entity. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Draft proposal for resolution process changes
* Russ Allbery [2021-09-28 20:50]: I find having an explicit process to use as a structure for navigating a disagreement to be calming and supportive. It makes me feel like I have firm ground under my feet and space to think when I know procedurally what I can and can't do in order to argue my perspective. [...] In contrast, it's hard to imagine a stronger rule set than a written program, which describes to a computer exactly what to do and leaves as little ambiguity as possible. But I find computer programs relaxing and enjoyable precisely because of that predictability. I'd like to highlight this point. It is not only about having explicit rules, it's also about making the whole process reasonably predictive. Chess has explicit rules, too, but I don't want Debian decisions to feel like I'm playing Chess against my fellow developers (also, I suck at Chess). Being able to outmaneuver proceedings by some unforeseen interaction of rules might be enjoyable for a courtroom movie, but it will invariably create "winners" and "losers", which is not a desirable social outcome. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Draft proposal for resolution process changes
* Russ Allbery [2021-09-28 09:04]: 6. If voting is started prior to two weeks after the original proposal via a call for a vote by a member of the Technical Committee, but another member of the Technical Committee objects more than two weeks after the original proposal but before the vote completes, the vote is still canceled. All members of the Technical Committee are then given 24 hours to add new ballot options or modify or withdraw the ballot options they have proposed. During this period no one may call for a vote. Following that 24 hour period, a new voting period automatically starts and cannot be canceled. Basically, there is a scenario where the vote could be canceled but the subsequent ensuing discussion period during which members can change their ballot options is so short as to be unfair (some of the committee is asleep) or unusable. What do you think of the following: 6. If a vote is canceled later than 13 days after the original proposal, the mandatory vote will be postponed and start 24 hours after the time of cancellation. Until then, no one may call for another vote. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Draft proposal for resolution process changes
* Russ Allbery [2021-09-28 09:24]: Thank you, this is a good idea. The advance reference to withdrawal is exactly why I didn't do that originally, but on further reflection I think it's fine. I now have as A.1.7: 7. The default option has no proposer or sponsors, and cannot be amended or withdrawn. and dropped the point that was A.2.4. In this context, 6.3.1.3. If all ballot options are withdrawn, the process is canceled. is slightly ambiguous, as the default option is technically also a ballot option. Maybe change it to "If all proposed ballot options…"? For that reason, I would also change 6.3.1.2 to read "Any member of the Technical Committee may *propose* additional ballot options", which also makes it consistent with the phrasing in A.1.1.2 Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
* Roberto C. Sánchez [2021-04-18 16:10]: 3:1 majority That would put a public statement on par with a change in the Constitution, which is a political statement in itself. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
* Roberto C. Sánchez [2021-04-18 16:10]: However, that seems likely to only work if there is a method for drafting the statement first and then simply having an up or down vote. No, because we have a ranking vote, where the majority is defined as the ratio of voters who prefer an option to the default versus those who do not. As you can see in the DPL election, both candidates achieved 4:1 majority, which would be impossible with a simple plurality vote. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
* Barak A. Pearlmutter [2021-04-18 20:30]: I'm suggesting that, since we came within a razor (just ONE BALLOT, as Adrian Bunk pointed out) of that situation actually occurring, we get in front of things, think about it, and figure out something proactive to prevent it from ever actually happening: to prevent us from ever having to make such an embarrassing press release. Maybe a public statement in the name of all developers should require more than a simple 1:1 majority? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: What does FD Mean
* Adrian Bunk [2021-04-11 20:53]: I am not saying people were stupid. Okay, that was hyperbolic. But you have to admit that you don't seem to put much confidence in people's ability (or willingness) to read the explanations that come with each ballot. I am by no means a voting system nerd and found them quite understandable. It can be hard to vote correctly in a voting system that is very different from what you are used to in real life, unless you are a nerd in voting systems. If you ask me as someone who has never used a ranked vote before, it is not that hard. The hard part is how the winner is determined from the votes. I don't think many people will bother to independently verify the results. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: What does FD Mean
* Adrian Bunk [2021-04-11 19:06]: Such a change would not remove any voting options since votes like 1--- have equivalent espressions like 1222. I disagree. Not on theoretical grounds, but if you assume that someone votes 1--- because they are too lazy to read the instructions, how do you think they will respond to an error message telling them they forgot to rank *all* options? Most likely, they'll vote 12345678. Besides, I am still unconvinced and mildly offended by the assumption that people who voted 1--- were too stupid to do it right. But for the sake of your argument, a much simpler solution would be a change in Devotee to report back the vote in normalized form, e.g. "Your vote has been recorded with the following effective rankings: 1222 1 Foo 2 Bar 2 Baz 2 Further Discussions If this is not your intention, please vote again with a corrected ballot." Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: What does FD Mean
* Sam Hartman [2021-04-08 08:33]: i think it's very presumptuous to assume anything about what someone should have voted because all those combinations are reasonable. And if anyone is really losing sleep over that question, they can still ask those ten voters if they intended to vote for systemd and were indifferent among the alternatives. -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: What does FD Mean
* Mathias Behrle [2021-04-03 10:22]: [ ] Further discussion [ ] Do nothing, leave the question unresolved [ ] None of the above The way I see it, all these have the same consequence for a vote (that is, none of the other options is acceptable). The Constitution will always permit another vote as long as K+1 developers introduce/sponsor it. And anyone who feels particularly strongly about continuing/terminating the discussion, will probably post it to debian-vote no matter what. - Timo signature.asc Description: PGP signature
Re: Announcing new decision making procedures for Debian
* Andrei POPESCU [2021-04-01 11:19]: Bonus points for writing the entire reply as an attached .doc, or even better .ppt, file (MS Office 1997 version or earlier). Kindly refer to the EBCDIC encoded WordStar document on my dial-in BBS for a thorough rebuttal. Cheers Timo signature.asc Description: PGP signature
Re: Re: Willingness to share a position statement?
It's not like it's a call to silence him forever. It is however a call to remove him from a position he appears to be unfit for. I agree with everything you are saying, but I note that the wording of the open letter is much harsher, with statements like "our communities have *no space* for people like Richard M. Stallman" (emphasis mine). FWIW, I would prefer something similar to the EFF statement [1], which conveys the same sentiment in a more neutral tone, so it's probably a better representation of the Debian project as a whole. This should not preclude anyone from signing the open letter if they wish, of course. - Timo [1] https://www.eff.org/deeplinks/2021/03/statement-re-election-richard-stallman-fsf-board signature.asc Description: PGP signature