Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
* Guillem Jover: " Proposal: Reaffirm our commitment to support portability and multiple implementations" (Sat, 30 Nov 2019 18:46:27 +0100): > X< > Title: Reaffirm our commitment to support portability and multiple > implementations > > The Debian project reaffirms its commitment to be the glue that binds > and integrates different software that provides similar or equivalent > functionality, with their various users, be them humans or other software, > which is one of the core defining traits of a distribution. > > We consider portability to different hardware platforms and software > stacks an important aspect of the work we do as a distribution, which > makes software architecturally better, more robust and more future-proof. > > We acknowledge that different upstream projects have different views on > software development, use cases, portability and technology in general. > And that users of these projects weight tradeoffs differently, and have > at the same time different and valid requirements and/or needs fulfilled > by these diverse views. > > Following our historic tradition, we will welcome the integration of > these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our distribution, > by reconciling these conflicts via technical means, as long as there > are people willing to put in the effort. > > This enables us to keep serving a wide range of usages of our distribution > (some of which might be even unforeseen by us). From servers, to desktops > or deeply embedded; from general purpose to very specifically tailored > usages. Be those projects hardware related or software based, libraries, > daemons, entire desktop environments, or other parts of the software > stack. > X< Seconded. Cheers Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpppRCShTFTa.pgp Description: Digitale Signatur von OpenPGP
Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
* Guillem Jover: " Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)" (Fri, 6 Dec 2019 21:51:50 +0100): > [ Sorry, resending signed this time around. :/ ] > > Hi! > > Ok, so here's what I'd like (or would have liked) to get into the ballot, > given the new context after the addition of the combined D+G option. But > it's not very clear to me whether this will be acceptable or not to the > Secretary, and what would be the actual procedure to replace the existing > option G with this one (as long as enough of the original sponsors are > fine with it), as I've found the way the procedure was applied/interpreted > to be rather confusing or perhaps not matching my memory of previous > instances. > > The changes to the original G are: > - Addition of Principles section title. > - s/tradeoffs/trade-offs/g. > - Addition of Guidance section. > > I'm CCing all the previous sponsors explicitly, just in case. > > > X< > Title: Reaffirm our commitment to support portability and multiple > implementations > > Principles > ~~ > > The Debian project reaffirms its commitment to be the glue that binds > and integrates different software that provides similar or equivalent > functionality, with their various users, be them humans or other software, > which is one of the core defining traits of a distribution. > > We consider portability to different hardware platforms and software > stacks an important aspect of the work we do as a distribution, which > makes software architecturally better, more robust and more future-proof. > > We acknowledge that different upstream projects have different views on > software development, use cases, portability and technology in general. > And that users of these projects weight trade-offs differently, and have > at the same time different and valid requirements and/or needs fulfilled > by these diverse views. > > Following our historic tradition, we will welcome the integration of > these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our distribution, > by reconciling these conflicts via technical means, as long as there > are people willing to put in the effort. > > This enables us to keep serving a wide range of usages of our distribution > (some of which might be even unforeseen by us). From servers, to desktops > or deeply embedded; from general purpose to very specifically tailored > usages. Be those projects hardware related or software based, libraries, > daemons, entire desktop environments, or other parts of the software > stack. > > Guidance > > > In the same way Debian maintainers are somewhat constrained by the > decisions and direction emerging from their respective upstreams, > the Debian distribution is also somewhat constrained by its volunteer > based nature, which has as another of its core defining traits, not > willing to impose work obligations to its members, while at the same > time being limited by its members bounded interests, motivation, energy > and time. > > Because of these previous constraints, trying to provide guidance in > a very detailed way to apply the aforementioned principles, is never > going to be satisfactory, as it will end up being inexorably a rigid > and non-exhaustive list of directives that cannot possibly ever cover > most scenarios, which can perpetuate possible current tensions. > > These will always keep involving case by case trade-offs between what > changes or requests upstreams might or might not accept, or the upkeep > on the imposed deltas or implementations the Debian members might need > to carry on. Which can never be quantified and listed in a generic and > universal way. > > We will also keep in mind that what might be considered important for > someone, might at the same time be considered niche or an uninteresting > diversion of time for someone else, but that we might end up being on > either side of the fence when sending or receiving these requests. > > We will be guided, as we have been in many other Debian contexts in the > past, by taking all the above into account, and discussing and evaluating > each situation, and respecting and valuing that we all have different > interests and motivations. That is in our general interest to try to > work things out with others, to compromise, to reach solutions or find > alternatives that might be satisfactory enough for the various parties > involved, to create an environment where we will collectively try to > reciprocate. And in the end and in most cases it's perhaps a matter of > just being willing to try. > X< > > > Thanks, > Guillem Seconded. -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgppRqJLqo0LT.pgp Description: Digitale Signatur von OpenPGP
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
* Timo Weingärtner: " Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms" (Fri, 26 Mar 2021 09:19:44 +0100): > Hallo Martin Michlmayr, > > 26.03.21 09:15 Martin Michlmayr: > > * Timo Weingärtner [2021-03-26 09:12]: > > > The Debian Project will issue a public statement on whether Richard > > > Stallman > > ^^ > > I think you forgot the word "not" here. > > Of course, thanks. > > Updated text: > ---8<---8<---8<--- > The Debian Project will not issue a public statement on whether Richard > Stallman should be removed from leadership positions or not. > > Any individual (including Debian members) is free to issue such statements or > (co-)sign any open letter. As a matter of course each individual is/shall be free to do so, we don't have to debate this right at all or in a GR. Furthermore I would like to have the wording restricted to the current document in question. Could this be changed to something along the lines: """ Any individual (including Debian members) wishing to (co-)sign the open letter in question is invited to do this in person. """ ? -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpOgTnLIYygw.pgp Description: Digitale Signatur von OpenPGP
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
* Michael Biebl: " Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms" (Sat, 27 Mar 2021 10:39:53 +0100): > Am 27.03.2021 um 01:48 schrieb Gunnar Wolf: > > Michael Biebl dijo [Fri, Mar 26, 2021 at 06:08:36PM +0100]: > >> ---8<---8<---8<--- > >> The Debian Project will not issue a public statement on whether Richard > >> Stallman should be removed from leadership positions or not. > >> > >> Any individual (including Debian members) wishing to (co-)sign any of the > >> open letters in question is invited to do this in person. > >> ---8<---8<---8<--- > > > > Language quip: Not "invited to do this in person" (personally flying > > to wherever signatures are being gathered), but "in a personal > > capacity" or "as an individual action"... ? > > I think the intention was clear, but I'm fine with a version which > changes that part as suggested above and my seconds extends to such a > version. Exactly my thoughts. I would be glad to hear from a native speaker if the wording is really capable of being misunderstood. Otherwise I just would let go. But I second also the proposed version, preferable using then "as an individual action". Cheers Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpBYwniN9yM3.pgp Description: Digitale Signatur von OpenPGP
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
* Timo Weingärtner: " Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms" (Sat, 27 Mar 2021 11:51:40 +0100): > Hallo Jonas, > > 26.03.21 20:42 Jonas Smedegaard: > > Quoting Calum McConnell (2021-03-26 20:14:50) > > > > > > Any individual (including Debian members) wishing to (co-)sign any > > > > of the open letters in question is invited to do this in person. > > > > > > "In person" is a bit unclear, given our times: can I sign it online? > > > How about just adding my name? > > > > > > I propose switching it to: > > > > Any individual (including Debian members) wishing to (co-)sign any > > > > of the open letters on this subject is strongly encouraged to do so. > > > > > > It also handles the fact that the open letters aren't really 'in > > > question', since there aren't any accepted amendments that mention > > > them. I also switched out "invite", because I feel that 'invite' > > > implies the ability to UN-invite (ie, block from signing), which is > > > not one that we possess. > > > > I was assuming that "in person" meant "individually", but I can see how > > it can instead mean "by showing up physically" which makes little sense > > in the context. > > > > Replacing "in person" with either "personally" or "individually" or "on > > their own" would in my opinion convey the same intended message as is my > > understanding (as a non-native english speaker) is the message now, and > > I would second proposal with such change. > > > > Removing "in person" would however loose what in my understanding is the > > central point of the message and making the central point implicit, > > causing it to risk becoming ambiguous (although I cannot think up right > > now how any examples of how other meanings could be read into it). I > > would hesitate seconding a proposal with the phrase removed. > > > > Replacing "invited to do this in person" with "strongly encouraged to do > > so" would in my opinion radically change the message from an unbiased > > "Debian does not recommend if you should personally support a petition > > or not" to a biased "Debian recommends that you personally support a > > petition". I would *not* second such changed proposal. > > I took "in a personal capacity" from Gunnar. > > > Replacing "in question" with "on this subject" seems to me to not change > > to meaning of the message. I would second a proposed text with that > > change. > > That's better actually, because it is not restricted to statements mentioned > in the vote. > > Updated text: > ---8<---8<---8<--- > The Debian Project will not issue a public statement on whether Richard > Stallman should be removed from leadership positions or not. > > Any individual (including Debian members) wishing to (co-)sign any of the > open letters on this subject is invited to do this in a personal capacity. > ---8<---8<---8<--- Seconded. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpvsb0oN24MB.pgp Description: Digitale Signatur von OpenPGP
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
* Steve Langasek: " Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms" (Sat, 27 Mar 2021 12:37:52 -0700): > On Sat, Mar 27, 2021 at 12:20:22PM +0100, Mathias Behrle wrote: > > > > Language quip: Not "invited to do this in person" (personally flying > > > > to wherever signatures are being gathered), but "in a personal > > > > capacity" or "as an individual action"... ? > > > > I think the intention was clear, but I'm fine with a version which > > > changes that part as suggested above and my seconds extends to such a > > > version. > > > Exactly my thoughts. I would be glad to hear from a native speaker if the > > wording is really capable of being misunderstood. Otherwise I just would let > > go. But I second also the proposed version, preferable using then "as an > > individual action". > > "in person" has a pretty unambiguous meaning in (American?) English > referring to physical presence, so is the wrong thing to say here for your > intent. Thanks, Steve, so we are on the safe side now. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpcjEMb8cH9C.pgp Description: Digitale Signatur von OpenPGP
Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»
* Gunnar Wolf: " Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»" (Fri, 2 Apr 2021 12:57:09 -0600): Thank you Gunnar for pushing this forward. > Nicolas Dandrimont dijo [Fri, Apr 02, 2021 at 06:27:48PM +0200]: > > > (...) > > > [A] Call for the FSF board removal, as in rms-open-letter.github.io > > > (proposed by Steve Langasek, currently base proposal) > > > > > > [B] Call for Stallman's resignation from FSF all bodies > > > (proposed by Sruthi Chandran, currently proposal B) > > > > > > [C] Discurage collaboration with the FSF while Stallman is in a leading > > > position (proposed by Santiago Ruano Rincón, currently proposal C) > > > > > > [D] Call on the FSF to further its governance processes > > > (proposed by Jonathan Wiltshire, currently proposal D) > > > > > > [E] Debian will not issue a public statement on this issue > > > (proposed by Timo Weingärtner, currently proposal E) > > > > > > [F] Support Stallman's reinstatement, as in rms-support-letter.github.io > > > (proposed by Timo Weingärtner, currently proposal A) > > > (...) > > > > I would suggest moving proposal E to the top or to the bottom of the > > ballot, as one can argue that this "status quo" option doesn't > > really fit within the "condemn → support" axis you've proposed. I > > think I agree with how the other options are ordered. > > Makes sense. OTOH, we usually take FD as "preserve status quo"; FD > usually appears (and should appear this time as well, sorry for not > capturing it in my ballot proposal) as the last option. I don't get that. Is this really common sense that FD means/meant "preserve status quo"? For me voting this option definitely should mean that further discussion on the topic is needed. > I understand, option E is not semantically identical to FD, but is > equivalent in the way that it means "do nothing project-wide, either > for or against". I consider the really great value of current option E that I can indeed vote explicitely that nothing should be done on behalf of the project and that further discussion is *not* needed. I agree that option E as the counterpart to all other options should be first or last, and my personal preference would be first. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: What does FD Mean
* Sam Hartman: " What does FD Mean" (Fri, 02 Apr 2021 16:57:28 -0400):
> >>>>> "Mathias" == Mathias Behrle writes:
>
> Mathias> I don't get that. Is this really common sense that FD
> Mathias> means/meant "preserve status quo"? For me voting this
> Mathias> option definitely should mean that further discussion on
> Mathias> the topic is needed.
>
>
> So, that is the denotation--that's what it literally means.
> In cases where things are thoroughly discussed to death, especially
> where it appears like all the options are on the table, it may well be
> that there is not momentum for further discussion, and FD acts a lot
> more like "no".
> It's a kind of no that allows someone to try and find a future option.
> It's more like "no not this moment," than "no and it would be rude to
> try and discuss more."
>
> But for a two option situation, option A do the thing and option B FD,
> FD probably does map to no fairly well.
I would really like to avoid this situation, where FD is expected to leave room
for such wide interpretations, especially if it is avoidable as easy as to
put at least some of the alternative options on the ballot. A ballot with only
'yes' and 'FD' should IMO just not happen.
As an example really to avoid I would like to give political votes in Germany.
There is not an option that says 'None of the above'. If I want to vote in this
direction I have two possibilities: to vote not at all or to vote with an
invalid ballot. Both options are completely unsatisfying and do not express my
intention. We can and should do better in Debian.
> In this situation, I think we'd have to look for the spread of votes.
> FD winning would probably either mean that we actually need to have
> further discussion (if a majority of people seemed to prefer one of the
> options to others, even though they ranked it below FD), or the project
> is too split to decide (if there were major splits below FD).
>
> In the first situation, I'd interpret it to mean that there was one
> direction that most people tended toward but that the specific option
> presented was not good enough.
> And so if there were energy, it would make sense to refine that option.
>
> But in the second situation where there were significant splits in
> support below FD, probably we ought conclude we don't have support for a
> common direction.
>
> So, yeah, FD is complicated:-)
Yes, there are a lot of assumptions ('probably', 'seemed to', 'interpret', 'we
ought to') in your text. Those could be at least partly avoided by putting
concise options on the ballot. FD as a fallback for all sort of missing options
falls back on us in the way that we do not know about our real intentions.
Let's make FD less complicated, please...;)
--
Mathias Behrle ✧ Debian Developer
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: What does FD Mean
* Pierre-Elliott Bécue: " Re: What does FD Mean" (Fri, 2 Apr 2021 23:29:58 +0200): > > So, yeah, FD is complicated:-) > > I'd rather have a None of the Above default option all the time along > with FD. It'd probably help. +1 -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: What does FD Mean
* Sam Hartman: " Re: What does FD Mean" (Fri, 02 Apr 2021 20:53:05 -0400): > >>>>> "Mathias" == Mathias Behrle writes: > > >> But for a two option situation, option A do the thing and option > >> B FD, FD probably does map to no fairly well. > > Mathias> I would really like to avoid this situation, where FD is > Mathias> expected to leave room for such wide interpretations, > Mathias> especially if it is avoidable as easy as to put at least > Mathias> some of the alternative options on the ballot. A ballot > Mathias> with only 'yes' and 'FD' should IMO just not happen. > > I think it's fine in cases where you have fairly strong confidence that > yes will win. > Let's say that for some reason we really needed a project statement that > the GPL was a DFSG-free license. > I think yes|FD would be fine. > Or for an example that actually happened, we needed a GR to replace > chairman with chair in the constitution. > In that case, I think yes|FD is fine. I see your use case, but I still think that even on such a topic there could be someone who thinks that the topic - for whatever reason - shouldn't be discussed at all. Why should they vote FD? NB: This applies in a way to the origin of the ongoing GR. For me the topic like it was brought into Debian doesn't belong to our responsibilities. How would we behave e.g. if someone from the ouside told us how we would have to elect our DPL? > Because if somehow FD wins, it's going to be a surprise. May be. But expectations or assumptions shouldn't be the base for ballot options. > I do agree that when we can articulate it, a terminal response like "do > nothing," is worth having on the ballot *if five people actually support > that*. > > In the case of the current GR, I think we do have a wide range of ballot > options. I almost agree, see below. > I'm reasonably sure that if FD wins it'll be because there's a > split--people would rather have the question remain open than see their > side lose, but no side can get a majority. > > I'm not sure that you can capture an option other than FD in such a > situation. > "do nothing," is not actually the same as leave the question unresolved. You are pointing here to a completely valid and meaningful option that is in no way covered by, yet even controversial to FD. I think that 'None of the above' comes quite near to 'do nothing, leave the question unresolved', but it would be indeed better to have it explicitely on the ballot. With the use cases of GRs coming to my mind (I certainly forgot some) I would consider as useful to have the following standard options on each ballot: [... other options ... ] [ ] Further discussion [ ] Do nothing, leave the question unresolved [ ] None of the above While I agree that we will never be able to put all options in every detail on the ballots the basic choices above would remove a lot of stress and uncertainty in the interpretation of FD. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
What does FD Mean (was: Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»)
* Russ Allbery: " Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»" (Fri, 02 Apr 2021 16:49:21 -0700): > Mathias Behrle writes: > > > I consider the really great value of current option E that I can indeed > > vote explicitely that nothing should be done on behalf of the project > > and that further discussion is *not* needed. > > I consider the naming of "further discussion" a wry joke on the fact that > the above outcome is, uh, unlikely. Good luck getting everyone in Debian > to stop discussing something. I am aware of the fact htat I won't stop discussions, but at least I do not want to be forced to say 'further discussion' if I just want the contrary. > I have no real objections to renaming "further discussion" to "none of the > above"; I just doubt it would accomplish anything and therefore am not > sure it's worth the effort. I would be glad if we would put more precise options on the ballot as I put it in my answer to Sam. Using 'None of the above' instead of 'FD' would be at least a first step into that direction. > And personally, not that anyone should make any decisions on this basis, I'm > kind of fond of the self-aware joke. It's good for us as a project to poke > fun at our own weaknesses, since it helps us keep them in mind. Yes, but joke aside it gives me really a hard time to say FD if I want exactly the contrary. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: GR: Change the resolution process (corrected)
* Wouter Verhelst: " Re: GR: Change the resolution process (corrected)" (Mon, 22 Nov 2021 17:15:34 +0200): > Text of the GR > == > > The Debian Developers, by way of General Resolution, amend the Debian > constitution under point 4.1.2 as follows. This General Resolution > requires a 3:1 majority. > > Sections 4 through 7 > > > Same changes as in Russ' proposal > > Section A > - > > Replace section A as per Russ' proposal, with the following changes: > > A.1.1. Strike the sentence "The maximum discussion period is 3 weeks". > > A.1.4. Strike in its entirety > > A.1.5. Rename to A.1.4. > > A.1.6. Strike in its entirety > > A.1.7. Rename to A.1.5. > > After A.2, insert: > > A.3. Extending the discussion time. > > 1. When less than 48 hours remain in the discussion time, any Developer >may propose an extension to the discussion time, subject to the >limitations of §A.3.3. These extensions may be seconded according to >the same rules that apply to new ballot options. > > 2. As soon as a time extension has received the required number of >seconds, these seconds are locked in and cannot be withdrawn, and the >time extension is active. > > 3. When a time extension has received the required number of seconds, >its proposers and seconders may no longer propose or second any >further time extension for the same ballot, and any further seconds >for the same extension proposal will be ignored for the purpose of >this paragraph. In case of doubt, the Project Secretary decides how >the order of seconds is determined. > > 4. The first two successful time extensions will extend the discussion >time by one week; any further time extensions will extend the >discussion time by 72 hours. > > 5. Once the discussion time is longer than 4 weeks, any Developer may >object to further time extensions. Developers who have previously >proposed or seconded a time extension may object as well. If the >number of objections outweigh the proposer and their seconders, >including seconders who will be ignored as per §A.3.3, the time >extension will not be active and the discussion time does not change. > > A.3. Rename to A.4. > > A.4. Rename to A.5. > > A.5. Rename (back) to A.6. Seconded. -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: GR: Change the resolution process (corrected)
* Wouter Verhelst: " Re: GR: Change the resolution process (corrected)" (Tue,
23 Nov 2021 09:53:50 +0200):
> aaand this should've been signed. Good morning.
Applies for me as well...
> > 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.
> >
> > --
> > w@uter.{be,co.za}
> > wouter@{grep.be,fosdem.org,debian.org}
Seconded.
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
pgpQoYfdQCOs8.pgp
Description: Digitale Signatur von OpenPGP
Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification
* Judit Foglszinger: " Ballot option 2 - Merely hide Identities of Developers
Casting a Particular Vote and allow verification" (Thu, 24 Feb 2022 05:44:34
+0700):
I sponsor this option.
Like others said: changing the vote system should be proposed in a
separate GR.
> I propose a ballot option for the GR
> "Hide Identities of Developers Casting a Particular Vote"
> that makes the following changes to the constitution.
>
> 1) Do not make the identity of a voter casting a particular vote public.
>
> 6) Codify that our election system must permit independent verification
>of the outcome given the votes cast and must permit developers to
>confirm their vote is included in the votes cast.
>
> So it's the proposed GR minus the changes
> not directly related to introducing secret votes.
>
> I ask for seconds aka sponsors for this Option.
>
> Rationale
> =
>
> Give the opportunity to vote for secret voting without needing to
> additionally vote for unrelated/only slightly related
> constitution changes;
> for example for the change of mode of voting
> from email to something not defined.
>
> As it was mentioned in the discussion,
> there might be no consensus on which options are direcly related -
> This option regards the need to allow verification (6))
> as directly related to secret votes, because otherwise
> they would become completely unverifiable.
>
> Summary of Changes
> ==
>
> 1) Do not make the identity of a voter casting a particular vote
>public.
>
> 6) Codify that our election system must permit independent verification
>of the outcome given the votes cast and must permit developers to
>confirm their vote is included in the votes cast.
>
>
> 4.2. Procedure
> @@ -228,9 +246,10 @@ earlier can overrule everyone listed later.
>
>Votes are taken by the Project Secretary. Votes, tallies, and
>results are not revealed during the voting period; after the
>vote the Project Secretary lists all the votes {+cast in sufficient
> detail that anyone may verify the outcome of the election from the votes
> cast. The+} {+ identity of a developer casting a particular vote is not
> made+} {+ public, but developers will be given an option to confirm
> their vote is included in the votes+} cast.
>
> @@ -371,8 +390,7 @@ earlier can overrule everyone listed later.
> necessary.
>
> The next two weeks are the polling period during which
> Developers may cast their votes. [-Votes in leadership elections are-]
> [- kept secret, even after the election is finished.-]{++}
>
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
pgpYUaT5eouJQ.pgp
Description: Digitale Signatur von OpenPGP
Re: Reaffirm public voting
* Philip Hands: " Re: Reaffirm public voting" (Fri, 04 Mar 2022 13:23:32 +0100): > Holger Levsen writes: > > > On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote: > >> 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. > > > > yes, that's what I ment, thanks. Do I need to resent my mail now with this > > change? :) > > I sponsor this. > > While I may not end up voting for it as my first option, I think it > deserves to be an explicit option, because I can imagine that no > super-majority emerges in this vote, and if that happens then we will be > able to draw rather different conclusions about the project consensus > depending upon whether this option comes above or below NotA (and by how > much). > > Cheers, Phil. I sponsor this as well. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpIZjIS7Pa98.pgp Description: Digitale Signatur von OpenPGP
Re: GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues
* Bill Allombert: " GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues" (Thu, 3 Mar 2022 00:10:53 +0100): > Dear developers, > > I propose the following ballot option for the current GR: > > Ballot Option > = > > 1) The Debian project decide against changing its voting process at this > time. > > 2) General resolutions that probe developpers opinions about non-technical > issues outside the social contract are discouraged. > > Rationale > = > > So far no voting scheme that preserve both the integrity of the vote and > the secret of the vote have been proposed. The scheme used for DPL > election does not provide plausible deniability. > > 2. is not made a hard requirement so that it need not be adjudicated by > the Debian secretary. However most of the developers that seconded the first > ballot of GR 2021_002 were experienced developers that would be have been > able to heed the recommendation given in this GR. > > Respectfully submitted, FTR I am sponsoring this. Whatever Bill and Holger decide about their similar options. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpI42JbWPVyu.pgp Description: Digitale Signatur von OpenPGP
Re: Changing how we handle non-free firmware
* Gunnar Wolf: " Re: Changing how we handle non-free firmware" (Mon, 22 Aug 2022 12:32:54 -0500): > I hereby propose the following alternative text to Steve's original > proposal. > > I'm only suggesting to modify the third paragraph, offering to produce > two sets of images (fully-free and with-non-free-firmware), being the > later more prominent. > > = > > We will include non-free firmware packages from the > "non-free-firmware" section of the Debian archive on our official > media (installer images and live images). The included firmware > binaries will *normally* be enabled by default where the system > determines that they are required, but where possible we will include > ways for users to disable this at boot (boot menu option, kernel > command line etc.). > > When the installer/live system is running we will provide information > to the user about what firmware has been loaded (both free and > non-free), and we will also store that information on the target > system such that users will be able to find it later. The target > system will *also* be configured to use the non-free-firmware > component by default in the apt sources.list file. Our users should > receive security updates and important fixes to firmware binaries just > like any other installed software. > > While we will publish these images as official Debian media, they will > *not* replace the current media sets that do not include non-free > firmware packages, but offered alongside. Images that do include > non-free firmware will be presented more prominently, so that > newcomers will find them more easily; fully-free images will not be > hidden away; they will be linked from the same project pages, but with > less visual priority. > > = Seconded. Thanks! -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpkBo0HqgHUk.pgp Description: Digitale Signatur von OpenPGP
Re: [RFC] General Resolution to deploy tag2upload
* Marco d'Itri: " Re: [RFC] General Resolution to deploy tag2upload" (Wed, 12 Jun 2024 14:37:25 - (UTC)): > deb...@kitterman.com wrote: > > >As I understand it, Debian was affected by the xz-utils hack, in part, > >because some artifacts were inserted into an upstream tarball that were not > >represented in the upstream git. Please explain how use of tag2upload is > >relevant to this scenario? I'm afraid I don't follow. > I think that it was assumed, and I agree, that a well-maintained Debian > git source tree has the upstream branch pulled from the upstream git > repository, keeping the complete history, and not created locally by > importing upstream tar release archives. Just as a note often forgotten in this discussion: There are upstreams, that don't use git and are even heavily opposed to git. Hopefully I have nevertheless "well-maintained Debian git source trees" for the Tryton suite... ;) -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Summary of the current state of the tag2upload discussion
* Russ Allbery: " Re: Summary of the current state of the tag2upload discussion" (Sun, 23 Jun 2024 10:55:00 -0700): > So rather than attacking me, you were insinuating attacks on other people. > I'm not sure that's any better. Sorry, I am unable to see a personal attack whatsoever when reading """ I think that can work both ways. I am old enough to have seen many instances of some new hotness coming along and any objection to it being swept aside because it was clear that the people objecting just didn't understand why the new hotness was so wonderful and why their concerns didn't matter anymore. My experience has been that when those concerns have been ignored (they usually are), things often don't end well. """ I think we have seen and still see with usrmerge how difficult and cumbersome the resolution of an initially as simple presented project turned out. I understand the answer of Scott directed in that way, at least this is a reservation of mine. I can understand the upcoming frustration of people that have invested a lot of energy in this thread, nevertheless I would like to return to the constructive discussion that evolved in the meantime. As was already said by others I would prefer at any rate a solution that could conciliate the demands of the proponents of this draft GR as well as those of the FTPmasters making the GR uncalled-for. IMHO the GR when happening will just result in a lot of frustration on the 'loosing' side. Please lets preserve the good energy and hard brain work invested in this thread so far, it is too precious to lose. Thanks Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list
* Gunnar Wolf: " Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list" (Thu, 1 Sep 2016 23:15:05 -0500): > === 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. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpxjlMzUuoUU.pgp Description: Digitale Signatur von OpenPGP
Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
Hi all,
I have set up an expiry on my GPG key:
- originally set to 2019-04-07
- updated on 2019-04-08 to 2021-04-06 and pushed to various keyservers
including keyring.debian.org.
But nevertheless my ballot is rejected, because obviously the old key is used
(s. the error report below).
What can I do to get my ballot tested against my actual updated key?
Do I have to wait for a keyring sync of the DD Keyring? When will it happen? Do
I have to get in touch with someone to get the key synced?
Thanks for your help
Mathias
This is an error report about your vote [record msg00118.raw]
for the vote
"Debian Project Leader 2019 Election"
sent in on Tue, 9 Apr 2019 09:38:59 +0200, with the subject
"Re: Debian Project Leader election 2019: First call for votes"
The message ID is <20190409093859.1fedb...@monsterix.mbehrle.de>.
The message base is msg00118.
The following errors were reported:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
There was a problem verifying the signature on the ballot.
FAILURE:
Reason: Failed to find valid signed message in mail body
[GNUPG:] NEWSIG
[GNUPG:] KEYEXPIRED 1554624896
[GNUPG:] KEY_CONSIDERED AC297E5C46B9D0B61C717681D6D09BE48405BBF6 0
[GNUPG:] KEYEXPIRED 1554624896
[GNUPG:] SIG_ID mwgOoKbGDJEFQ223bQPUVlc417w 2019-04-09 1554795539
[GNUPG:] KEYEXPIRED 1554624896
[GNUPG:] KEY_CONSIDERED AC297E5C46B9D0B61C717681D6D09BE48405BBF6 0
[GNUPG:] EXPKEYSIG D6D09BE48405BBF6 Mathias Behrle
[GNUPG:] VALIDSIG AC297E5C46B9D0B61C717681D6D09BE48405BBF6 2019-04-09
1554795539 0 4 0 1 10 01 AC297E5C46B9D0B61C717681D6D09BE48405BBF6
The ballot decrypted correctly, but was not signed
So this means that either the ballot was not signed at all
or that it uses RFC 1847 Encapsulation, where the ballot
is first signed as a multipart/signature body, and then
encrypted to form the final multipart/encrypted body --
but something went wrong in verifying the signature.
In either case, the ballot is being rejected.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
gpg: WARNING: unsafe permissions on homedir
'/srv/vote.debian.org/data/leader2019' gpg: encrypted with 4096-bit RSA key, ID
3593ACB276DCAEE3, created 2010-06-01 gpg: encrypted with 4096-bit RSA key, ID
F9DFF93A59673F5A, created 2019-04-06 [GNUPG:] ENC_TO F9DFF93A59673F5A 1
0[GNUPG:] KEY_CONSIDERED 58D81C29D1ABF34205B6F94C08E10B984F95AED7 0[GNUPG:]
KEY_CONSIDERED 58D81C29D1ABF34205B6F94C08E10B984F95AED7 0[GNUPG:] ENC_TO
3593ACB276DCAEE3 1 0[GNUPG:] KEYEXPIRED 1554624896[GNUPG:] KEY_CONSIDERED
AC297E5C46B9D0B61C717681D6D09BE48405BBF6 0[GNUPG:] NO_SECKEY
3593ACB276DCAEE3[GNUPG:] KEY_CONSIDERED
58D81C29D1ABF34205B6F94C08E10B984F95AED7 0[GNUPG:] BEGIN_DECRYPTION[GNUPG:]
DECRYPTION_INFO 2 9[GNUPG:] PLAINTEXT 62 1554795539 [GNUPG:]
DECRYPTION_OKAY[GNUPG:] GOODMDC[GNUPG:]
END_DECRYPTION-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This ballot is being rejected.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
If you have already voted again, please ignore this.
You can always get a new ballot by mailing
bal...@vote.debian.org with the subject "leader2019"
The time now is Tue Apr 9 07:40:03 2019
Thanks for your participation.
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
* Joerg Jaspert: " Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)" (Tue, 09 Apr 2019 12:12:10 +0200): Hi Joerg, thanks for your answer. > 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. Yes, I got now aware of this. > > Do I have to wait for a keyring sync of the DD Keyring? When will it > > happen? Do > > I have to get in touch with someone to get the key synced? > > Yes, same as for the archive and uploads. > > 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. If so then I think there is a clear gap in the procedures. - What about DDs being approved just during the voting period? They should clearly be able to vote. - What about DDs losing their right during the voting period? Should their ballots be valid? Regarding the update of the expiration date I surely was late, but nevertheless the procedure itself is considered best practice [1][2], so it is absolute legitimate in my understanding. To cover cases like mine it would probably be good practice to update the keyring at least shortly before the end of the voting period. Of course I understand very well that the workload on the keyring maintainers should be kept at a reasonable size. Anyway I will now contact KeyringMaint and Secretary to see if we can find a way to solve the problem. Thanks again Mathias [1] https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years [2] http://www.g-loaded.eu/2010/11/01/change-expiration-date-gpg-key/ -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgp85vlCLjapS.pgp Description: Digitale Signatur von OpenPGP
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
* Mattia Rizzolo: " Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)" (Tue, 9 Apr 2019 13:16:43 +0200): Hi Mattia, > 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. Also thanks to you, at least it is now clear to me what happened and what to try. Cheers Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpwCi985Xbjl.pgp Description: Digitale Signatur von OpenPGP
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
* Ian Jackson: " Re: Failing GPG key (was: Re: Debian Project Leader election
2019: First call for votes)" (Tue, 9 Apr 2019 12:13:32 +0100):
Hi Ian,
> Joerg Jaspert writes ("Re: Failing GPG key (was: Re: Debian Project Leader
> election 2019: First call for votes)"):
> > *Usually* they do not do that during running elections, just short
> > before they start, so you may be out of luck.
>
> In that case I think the Secretary should make some alternative
> arrangements, since (i) there is no doubt that Matthias is eligible to
> vote (ii) it will be possible to verify the authenticity of Matthias's
> vote, albeit by using an ad-hoc or alternative arrangement.
Indeed and thanks for confirming. In principle my refused ballots are valid
(i.e. signed with a valid key), but they are checked against an invalid key.
As previously said in my answer to Joerg I will try to find a way with
KeyringMaint and/or Secretary to get a solution.
Cheers
Mathias
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
* Joerg Jaspert: " Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)" (Tue, 09 Apr 2019 16:44:43 +0200): > On 15367 March 1977, Mathias Behrle wrote: > > >> *Usually* they do not do that during running elections, just short before > >> they start, so you may be out of luck. > > If so then I think there is a clear gap in the procedures. > > That may be, though they are like this for a long time now. I understand, despite long standing procedures don't justify themselves only for their long time being. > > - What about DDs being approved just during the voting period? They should > > clearly be able to vote. > > It has always been avoided to add new DDs during voting period to avoid > accusations of "rig a vote by letting the right people join at that > moment". Could as well be phrased: "rig a vote by not letting in the right people";) > > - What about DDs losing their right during the voting period? Should their > > ballots be valid? > > That also hasn't happened that I can remember. And hopefully won't in the future. But the possibility exists. > > To cover cases like mine it would probably be good practice to update the > > keyring at least shortly before the end of the voting period. Of course I > > understand very well that the workload on the keyring maintainers should > > be kept at a reasonable size. > > I can see value in both ways, but I keep myself out of this. Not for me > to say, I just reported on the current state as I know it. Thanks again, Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
* Roberto C. Sánchez: " Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)" (Tue, 9 Apr 2019 13:03:43 -0400): > On Tue, Apr 09, 2019 at 06:21:52PM +0200, Mathias Behrle wrote: > > * Joerg Jaspert: " Re: Failing GPG key (was: Re: Debian Project Leader > > election 2019: First call for votes)" (Tue, 09 Apr 2019 16:44:43 +0200): > > > > > On 15367 March 1977, Mathias Behrle wrote: > > > > [...] > > > > > > It has always been avoided to add new DDs during voting period to avoid > > > accusations of "rig a vote by letting the right people join at that > > > moment". > > > > Could as well be phrased: "rig a vote by not letting in the right people";) > > > That would only be the case if the key were removed intentionally by > someone other than the owner of the key. I have an expiry set on my own > key and that therefore makes me, and only me, responsible to ensure that > I update the expiry when necessary to avoid problems. Could it be that you missed the smiley and that we talked in the cited paragraph about something completely different than key expiries? Apart from that you are completely right in assuming my responsibility. Cheers Mathias -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
* Kurt Roeckx: " Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)" (Tue, 9 Apr 2019 19:10:04 +0200): > In my expierence, they do update the keyring during the voting > period because each year some people run into this problem. I > suggest you that you send the updated key to keyring.debian.org > and contact them in case you have this problem. That's already done. If the keyring is updated once more during the voting period this will be perfectly fine for me and I will be in position to vote again. > There can be various reason why people that have the right to vote > are not able to do so. If that reason can't be resolved, I'm > willing to manually add the vote. I prefer not to do this, and > have never done so before. If it really can't be resolved, you > can contact the secretary. I will have at least the following > rules for such vote casts: > - The vote needs to be cast during the voting period. > - You should have a good reason why the normal procedure doesn't > work for you > - I need some way to authenticate you Well noted, this will be kind of last ressort. Thanks for your help, Mathias -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Failing GPG key
* Russ Allbery: " Re: Failing GPG key" (Tue, 09 Apr 2019 10:17:15 -0700): > All discussion of the right way to handle keyring updates for a vote > aside, this is a good reminder that one of the drawbacks of setting key > expirations is that bumping the expiration date (or adding a new subkey) > is a bit more involved than it may appear and takes a while to propagate. > > I bump the expiration date or generate a new subkey six months before the > current one will expire, and immediately push the new one to both the > general keyserver network and to keyring.debian.org. Since I started > doing that, I've not had any problems; before that, I would occasionally > have trouble uploading to the backports archive or other issues due to > slower keyring updates. Unless you have a specific application in mind > for a faster key expiration, I can recommend that practice as one that > seems to avoid issues. I will do exactly like you explained in the future. The time frames needed to get seamless functionality are indeed substantially longer than I had expected in the first place. > (This is not to imply in any way that this is your fault. I found this > aspect of things quite unintuitive myself.) Thanks for the further aspects to keep in mind. As for me I *was* too late in resetting the expiry. Shit happens. I don't think that will happen again;) Cheers Mathias -- Mathias Behrle ✧ Debian Developer PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
* Gunnar Wolf: " Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)" (Tue, 9 Apr 2019 21:58:43 -0500): Hi Gunnar, > > FWIW, I already sent Mathias a private mail about this, as he also > asked this privately :) But this seems to be of general interest, so... Thanks a lot, I am answering here then. >> - What about DDs being approved just during the voting period? They should >> clearly be able to vote. >> - What about DDs losing their right during the voting period? Should their >> ballots be valid? > > Right. I am aware of both cases (well, of the second; given that key > addition is one of the last steps of an account creation, the first > case is basically impossible). Why is the first case impossible? Because DAM doesn't process accounts during vote periods? > We often did an upload on the day just > before a call for votes (we didn't this time, as we have adopted > during last year a time-based cycle which seems to work well and > reliably; keyring gets updated on the 24-25 every month). > > As I said on the private mail: I am set to do the April keyring > upload. If the Secretary acknowledges this will cause no unforseen > effects on the already tallied votes, I see no issues with doing it a > couple of days earlier. But I am not familiar with devotee or other > issues that might rise, and I don't want to break vote processing for > others. Looking forward to the response of Secretary and thanks for the explanations! Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpZJvrGmjmvV.pgp Description: Digitale Signatur von OpenPGP
Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)
* Adriano Rafael Gomes: " Re: Failing GPG key (was: Re: Debian Project Leader election 2019: First call for votes)" (Fri, 19 Apr 2019 00:44:26 -0300): > On Tue, Apr 09, 2019 at 10:19:10AM +0200, Mathias Behrle wrote: > >Hi all, > > > >I have set up an expiry on my GPG key: > >- originally set to 2019-04-07 > >- updated on 2019-04-08 to 2021-04-06 and pushed to various keyservers > > including keyring.debian.org. > > > >But nevertheless my ballot is rejected, because obviously the old key is used > >(s. the error report below). > > > >What can I do to get my ballot tested against my actual updated key? > > Hi Mathias, > > I'm in a similar situation, and I've managed to get my vote accepted > using my masterkey instead of my subkey to sign my vote. Hi Adriano, there was a recent keyring update just in time so I could vote without problems in the meantime. Perhaps this also solved your problem or did you not set an expiry on your master key? Cheers -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
