Re: [RFC] General Resolution to deploy tag2upload

2024-06-16 Thread Timo Röhling

* 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

2024-06-16 Thread Timo Röhling

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

2024-06-13 Thread Timo Röhling

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

2024-06-13 Thread Timo Röhling

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

2024-06-13 Thread Timo Röhling

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

2023-03-16 Thread Timo Röhling

* 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

2022-09-14 Thread Timo Röhling

* 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

2022-08-18 Thread Timo Röhling

* 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

2022-03-28 Thread Timo Röhling

* 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

2022-03-06 Thread Timo Röhling

* 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

2022-03-05 Thread Timo Röhling

* 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

2022-03-05 Thread Timo Röhling

* 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

2022-02-17 Thread Timo Röhling

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)

2021-11-26 Thread Timo Röhling

* 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)

2021-11-20 Thread Timo Röhling
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

2021-11-11 Thread Timo Röhling

* 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

2021-11-08 Thread Timo Röhling

* 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

2021-11-04 Thread Timo Röhling

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)

2021-10-06 Thread Timo Röhling

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

2021-09-29 Thread Timo Röhling

* 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

2021-09-28 Thread Timo Röhling

* 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

2021-09-28 Thread Timo Röhling

* 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

2021-04-18 Thread Timo Röhling

* 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

2021-04-18 Thread Timo Röhling

* 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

2021-04-18 Thread Timo Röhling

* 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

2021-04-11 Thread Timo Röhling

* 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

2021-04-11 Thread Timo Röhling

* 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

2021-04-09 Thread Timo Röhling

* 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

2021-04-03 Thread Timo Röhling

* 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

2021-04-01 Thread Timo Röhling

* 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?

2021-03-25 Thread Timo Röhling

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