Re: DDs with no key in the keyring [was: Please include unique voters in GR graphs]
On Fri, Dec 27, 2019 at 10:08:44PM +0100, Thomas Goirand wrote: > So, this means there's 101 DDs that don't have a GPG key in the keyring? > Wow, that's a big amount. Do we have an idea of how long these DDs are > in that state? Why are they still DDs? Because apparently kicking them out without a proper investigation takes time, and the MIA process, i.e. the only accepted "investigation" method, likewise take a ton of time (and the fairly limited amount of empathy from the people doing it). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: DDs with no key in the keyring [was: Please include unique voters in GR graphs]
On Sat, Dec 28, 2019 at 06:14:40PM +0100, Thomas Goirand wrote: > > Because apparently kicking them out without a proper investigation takes > > time, and the MIA process Looks like I botchered this sentence. This should have read: "because apparently kicking them out without a proper investigation is not acceptable, and the MIS processâŠ" > > i.e. the only accepted "investigation" > > method, likewise take a ton of time (and the fairly limited amount of > > empathy from the people doing it). > > You have all my sympathy and respect for doing what you do! :) If it can comfort you, I think there were like an hundred more a couple of years ago or somesuch (number coming out of my mind). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Debian Project Leader Election 2020 Results
On Sun, Apr 19, 2020 at 02:18:16PM +0200, Debian Project Secretary - Kurt Roeckx wrote: > Stats for the DPL votes: > |--+--++---++-++---| > | | Num || Valid | Unique | Rejects | % | Multiple | > | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | > |--+--++---++-++---| > | 1999 | 347 | 27.942 | |208 | | 59.942 | 7.44399 | > | 2000 | 347 | 27.942 | |216 | | 62.248 | 7.73030 | > | 2001 | ?? | ?? | |311 | || | > | 2002 | 939 | 45.965 | 509 |475 | 122 | 50.586 | 10.33395 | > | 2003 | 831 | 43.241 | 510 |488 | 200 | 58.724 | 11.28559 | > | 2004 | 908 | 45.200 | 506 |482 | 52 | 53.084 | 10.66372 | > | 2005 | 965 | 46.597 | 531 |504 | 69 | 52.228 | 10.81615 | > | 2006 | 972 | 46.765 | 436 |421 | 41 | 43.313 | 9.00246 | > | 2007 | 1036 | 48.280 | 521 |482 | 267 | 46.525 | 9.98343 | > | 2008 | 1075 | 49.181 | 425 |401 | 35 | 37.302 | 8.15356 | > | 2009 | 1013 | 47.741 | 366 |361 | 43 | 35.636 | 7.56155 | > | 2010 | 886 | 44.648 | 459 |436 | 88 | 49.210 | 9.76513 | > | 2011 | 911 | 45.274 | 402 |392 | 93 | 43.030 | 8.65836 | > | 2012 | 948 | 46.184 | 436 |403 | 72 | 42.511 | 8.72589 | > | 2013 | 988 | 47.149 | 402 |390 | 73 | 39.474 | 8.27170 | > | 2014 | 1003 | 47.505 | 412 |401 | 61 | 39.980 | 8.44117 | > | 2015 | 986 | 47.101 | 364 |353 | 39 | 35.801 | 7.49454 | > | 2016 | 1023 | 47.977 | 286 |282 | 74 | 27.566 | 5.87787 | > | 2017 | 1062 | 48.882 | 327 |322 | 57 | 30.320 | 6.58729 | > | 2018 | 1001 | 47.457 | 343 |333 | 53 | 33.266 | 7.01674 | > | 2019 | 1003 | 47.505 | 389 |378 | 59 | 37.687 | 7.95701 | > | 2020 | 1011 | 47.694 | 352 |339 | 33 | 33.531 | 7.10776 | > |--+--++---++-++---| The number of rejects keeps weirding me out. It's not has high as 2007 where more than half (?!) of the votes were rejected, but it's still looming around a 10%. So I'd have some questions: * Are rejected votes that are then retried and validated still counted as rejects? * what constitutes a reject? * if the rejects are caused by formatting issues in the voting mail (I never tried nor ever had a rejected vote myself), can something be made to have the voting be less brittle? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Renaming the FTP Masters
Just dropping my 2cents: On Sat, 6 Nov 2021, 12:09 am Felix Lechner, wrote: > On Fri, Nov 5, 2021 at 2:45 PM Joerg Jaspert wrote: > > > > I am pretty sure that was a 100% calculated move > > to go directly to this. > > 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?) > If I was given the question: would you like to get rid of the word "master" because it reminds somebody of slavery, my answer would be NO. (Incidentally, I have similar thoughts about blacklist/whitelist and similar SJW crap) In fact, depending how the ballots are worded, I might just even vote against this specific proposal. Let's lose the fear of referendums. Our fellow contributors are our > trusted partners in this noble endeavor! > But I do support this stance. I'd love to see something like GRs used way way more often, if only the process was much lighter in bureaucracy đ€
Re: GR: Change the resolution process (corrected)
> > 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 changes: > > > > A.1.1. Replace the sentence "The minimum discussion period is 2 weeks." > >by "The initial discussion period is 1 week." 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.3.6 (now A.4.6): replace 'A.3.4' by 'A.4.4'. > > > > A.4. Rename to A.5. > > > > A.4.2 (now A.5.2): replace '§A.5' by '§A.6'. > > > > A.5. Rename (back) to A.6. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Reaffirm public voting
On Fri, Mar 04, 2022 at 10:42:51AM +, 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. If I were to add my thoughts: political GRs don't belong in Debian, please take them elsewhere. For non-political votes there is no use for private voting. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Reaffirm public voting
On Fri, Mar 04, 2022 at 06:41:54AM -0500, Tiago Bortoletto Vaz wrote:
> On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott BĂ©cue wrote:
> > I'm pretty sure some gave double thoughts before voting because of the
> > shitstorm/flame that had happened before the vote.
>
> This has been argued already it seems.
Yes, it's already been discussed, I doubt it needs to be discussed even
more here, and I surely don't want to.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Draft ballot voting secrecy GR
I don't think you updated this template after the last GR:
On Sat, Mar 12, 2022 at 06:09:20PM +0100, Kurt Roeckx wrote:
> [ ] Choice 1: Hide identities of Developers casting a particular vote
> [ ] Choice 2: Hide identities of Developers casting a particular vote and
> allow verification
> [ ] Choice 3: Reaffirm public voting
> [ ] Choice 4: Further Discussion
AFAIK, FD doesn't exist anymore, this should be NOTA now.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: General Resolution: Liquidate donated assets as soon as possible
On Mon, Jun 20, 2022 at 02:31:12PM -0400, Louis-Philippe VĂ©ronneau wrote: > I don't see GRs as "adversarial" or "a last resort to put a nail in the > coffin of a divisive debate", but as a great tool we have to take > collective decisions. I think we can have "nice" GRs without obvious > conflicts, and they don't inherently have to be painful or exhausting. GRs have another great problem, IMHO. They are pretty much a final solution, not very dissimilar to some country's law. Once a GR pass, the project has no way to behave differently than what's was voted, save to have another GR to repeal the previous one. Even ignoring if this particular vote should be done or not (spoiler: I'd likely vote NOTA over anything here), I believe it would be too stifling to force TOs to do that when there might be good reasons not to in some specific case that we can't foresee. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
m authoritarian > governments; handing threat actors exploits they can use for oppression > is against what Debian stands for. > > e. Developers and companies will downplay security issues because > a "security" issue now comes with legal implications. Less clarity on > what is truly a security issue will hurt users by leaving them vulnerable. > > 3. While proprietary software is developed behind closed doors, Free > Software development is done in the open, transparent for everyone. To > keep even with proprietary software the open development process needs > to be entirely exempt from CRA requirements, just as the development of > software in private is. A "making available on the market" can only be > considered after development is finished and the software is released. > > 4. Even if only "commercial activities" are in the scope of CRA, the > Free Software community - and as a consequence, everybody - will lose a > lot of small projects. CRA will force many small enterprises and most > probably all self employed developers out of business because they > simply cannot fullfill the requirements imposed by CRA. Debian and other > Linux distributions depend on their work. It is not understandable why > the EU aims to cripple not only an established community but also a > thriving market. CRA needs an exemption for small businesses and, at the > very least, solo-entrepreneurs. > > == > > > 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 proposals and links: > > https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive > > (2) Background information: > > https://blog.documentfoundation.org/blog/2023/01/24/tdf-position-on-eus-proposed-cyber-resilience-act/ > > https://blogs.eclipse.org/post/mike-milinkovich/european-cyber-resilience-act-potential-impact-eclipse-foundation > > https://labs.ripe.net/author/maarten-aertsen/open-source-software-vs-the-proposed-cyber-resilience-act/ > https://blog.opensource.org/author/webmink/ > Detailed > analysis: > https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/13410-Cyber-resilience-act-new-cybersecurity-rules-for-digital-products-and-ancillary-services/F3376542_en > > (3) Debian Social Contract No. 2, 3 and 4 > https://www.debian.org/social_contract > > - GENERAL RESOLUTION ENDS - > > Cheers, > > -- Santiago -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Proposed GR: Acknowledge that the debian-private list will remain private
On Thu, Jul 07, 2016 at 03:37:08PM +0200, Nicolas Dandrimont wrote: > We therefore propose the following General Resolution: > > === BEGIN GR TEXT === > > Title: Acknowledge that the debian-private list will remain private. > > 1. The 2005 General Resolution titled "Declassification of debian-private >list archives" is repealed. > 2. In keeping with paragraph 3 of the Debian Social Contract, Debian >Developers are strongly encouraged to use the debian-private mailing >list only for discussions that should not be disclosed. > > === END GR TEXT === Seconded. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: draft ballot
On Sat, Apr 01, 2017 at 09:30:41PM +0200, Kurt Roeckx wrote:
> Here is the draft ballot.
Thanks for it!
This draft does not contain any information regarding the secrecy of the
vote. I know that the vote will be secret (according to the
consttution), but in the recentish past there was a thread asking for
this detail to be specified in the ballot, and I think it should be
outlined in this one too.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: DPL 2019 nomination
On Thu, Mar 14, 2019 at 09:38:52AM -0400, Sam Hartman wrote:
> I've been pondering this over the last week and dealing with things like
> getting authorization from my employer.
Can you share more details on your availability? I.e., how many hours a
week does your employer allow you to spend on DPL duties? etc, etc.
> I've been struggling to find the right place to help Debian work better
> together and to help people solve problems without so much escalation
Any other area you'd work on? If so, what "improvements" would be
working toward?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
On Tue, Apr 09, 2019 at 12:12:10PM +0200, Joerg Jaspert wrote: > On 15367 March 1977, Mathias Behrle wrote: > > > - originally set to 2019-04-07 > > - updated on 2019-04-08 to 2021-04-06 and pushed to various keyservers > > including keyring.debian.org. > > That was a bit late, but the right place to send to. FYI, the last keyring update was done on 2019-03-24, and they are generally done monthly. So, yes, late. > Updates send to keyring.d.o are not automagically included in the > keyrings the debian infratructure uses. It needs a keyring maint to run > some tool. > > *Usually* they do not do that during running elections, just short before > they start, > so you may be out of luck. You could try to contact the keyring-maint team, maybe they are willing to do an ad-hoc update to include your key, but I expect you'll be out of luck. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
