> "Andreas" == Andreas Tille writes:
Andreas> I would really love to see some mails / logs of discussion
Andreas> between tag2upload developers and ftpmaster team. Is there
Andreas> any chance that we could bring the involved parties in one
Andreas> (virtual) room and discuss
> "Sean" == Sean Whitton writes:
Sean> = BEGIN FORMAL RESOLUTION TEXT
Sean> tag2upload allows DDs and DMs to upload simply by using the
Sean> git-debpush(1) script to push a signed git tag.
Sean> 1. tag2upload, in the form designed and implemented by Sean
Sean> Whitt
> "Sean" == Sean Whitton writes:
Sean> Hello everyone, I seek seconds for the General Resolution at
Sean> the end of this e-mail. The preceding sections are an
Sean> introductory explanation and rationale.
Sean> We have reviewed the discussion we've already had and prepared
> "Matthias" == Matthias Urlichs writes:
Matthias> A reproducibility checker for t2u seems like child's play,
Matthias> compared to that effort. While no t2u checker currently
Matthias> exists, somebody might be motivated enough to write
Matthias> one. (Hint, hint …)
You don'
> "Russ" == Russ Allbery writes:
Russ> I worked on an update of my security review last night to take
Russ> into account the additional concerns that people have raised
Russ> and other feedback. I wrote a whole bunch of words about this
Russ> specifically because I don't think
> "Salvo" == Salvo Tomaselli writes:
>> In this sense, the history is like comments. You wouldn't think
>> it was still the source code if all the comments had been
>> stripped out.
Salvo> But if by mistake one upstream adds a proprietary file in git
Salvo> and then remo
> "Ian" == Ian Jackson writes:
Ian> Gerardo Ballabio writes ("What is the source code (was: [RFC]
Ian> General Resolution to deploy tag2upload)"):
>> Paul R. Tagliamonte wrote:
>> > I wonder if we have a good idea of what the project believes to
>> be the case between #1 a
> "Russ" == Russ Allbery writes:
>> 2) Attacker possibly through a compromise of the dgit server and
>> salsa changes the git view to be something harmless.
Sorry I was assuming that the web ui and the git repository were still
consistent, but were inconsistent with what was uploa
TL;DR: I think a GR is an appropriate tool for making this decision at
this time. I disagree with Simon's characterization of the TC's powers
and think it is valuable for us to think broadly about all the tools we
have for making decisions, so I am responding here.
> "Simon" == Simon McVittie
> "Russ" == Russ Allbery writes:
Russ> The attack that Simon is talking about doesn't require a
Russ> preimage attack, only a successful collision attack against
Russ> Git trees using SHAttered plus some assumptions about where
Russ> Git may be lazy about revalidating hashes.
I will write a more detailed response to Russ's analysis later.
I am behind on getting my packages into shape and I want to concentrate
on that for now.
I do agree with Russ's basic conclusion: we should decide whether to
adopt tag2upload for reasons other than security of the architecture.
> "Adrian" == Adrian Bunk writes:
Adrian> If I send an email requesting all data Debian has about me to
Adrian> data-protect...@debian.org, will I receive a complete reply within
the
Adrian> expected time, including all data members of delegations like the
Adrian> Debian Ac
> "Andreas" == Andreas Tille writes:
Andreas> I was told in private that a daily log in Git might be a bit tough
but
Andreas> I hope to manage. I consider it a good preparation for the
monthly Bits.
I think I recall inheriting some infrastructure from Chris for
maintaining some DPL
> "Roberto" == Roberto C Sánchez writes:
Roberto> I can infer that you likely view the current ratio of around 3%
women
Roberto> (33/1004) and around 96% men ((1004-33)/1004) [0] (and, yes, I
recognize
Roberto> that this does not account for gender minority individuals, but I
wa
> "Thomas" == Thomas Koch writes:
Thomas> A question to DPL candidates
Generally we mwait until the campaining period for questions to the
candidates.
I mean it's a list, you can post to it whenever, but those conventions
do help us.
> "Bart" == Bart Martens writes:
>>
>> * A commercial company writes free-software that for all
>> practical purposes can be used only for access to their
>> proprietary web service. I'd rather not allow arguments about
>> whether a flaw is on the web service side or the
> "Bart" == Bart Martens writes:
Bart> On Wed, Nov 15, 2023 at 02:52:31PM +0100, Lucas Nussbaum wrote:
>> I wonder if we should have something like "Free software
>> development by nonprofit organizations" somewhere.
Bart> Are we now drawing a line between profit and nonprofi
> "Roberto" == Roberto C Sánchez writes:
Roberto> I'm afraid that you miss the point. I specifically chose
Roberto> flat earth, & co., as a contrast. My position is that we
Roberto> are all adults, capable of deciding for ourselves and that,
Roberto> absent some behavior that
> "Milan" == Milan Kupcevic writes:
Milan> Pollo,
Milan> I trust your best intention but I hold that these decisions
Milan> should be worked out by the Project Leader and/or appointed
Milan> delegates in coordination with TOs and with help of qualified
Milan> advisers. Th
> "Adrian" == Adrian Bunk writes:
Adrian> Your "services" approach does not work for the non-trivial
Adrian> cases where Debian might be a (joint) controller of personal
Adrian> data.
Adrian> The Debian Community Team promises confidentiality regarding
Adrian> personal inf
> "Kurt" == Kurt Roeckx writes:
>> It inadvertently weakened the constitutional protection against
>> changes to the constitution.
Kurt> I currently fail to see how it does.
I think Felix's point is that if we had choice 1, 2 and Nota,
People who preferred option 3 would vote
> "Richard" == Richard Laager writes:
Richard> On 3/20/22 07:10, Felix Lechner wrote:
>> If we accidentally formed a General Partnership, as has been
>> suggested elsewhere
Richard> Yes, that would be really dumb for a number of reasons.
The problem is that at least in the U
> "Jonathan" == Jonathan Carter writes:
Jonathan> I installed a Jitsi server for Debian (it's a system for
Jonathan> making group video calls), and was really proud that we
Jonathan> had this... until we had some blind people join some calls
Jonathan> and learned how utterly in
>>>>> "Kurt" == Kurt Roeckx writes:
Kurt> On Mon, Mar 07, 2022 at 03:12:57PM -0700, Sam Hartman wrote:
>> >>>>> "Judit" == Judit Foglszinger writes:
>>
>> >> I think it would be clearer to add "
> "Judit" == Judit Foglszinger writes:
>> I think it would be clearer to add "that" between "confirm" and
>> "their":
>>
>> {+ public, but developers will be given an option to confirm that
>> their vote is included in the votes+} cast.
Judit> I agree. It makes this
> "Thorsten" == Thorsten Glaser writes:
>> At the same time it relaxes the requirement that the secretary
>> must conduct a vote via email. There are no current plans to
>> move away from
Thorsten> This is a very bad idea.
Hi.
Several of the issues you brig up are legitimat
> "Ansgar" == Ansgar writes:
Ansgar> Would removing the trailing space introduced by these
Ansgar> changes require a separate GR? There are also other similar
Ansgar> inconsistencies, e.g., one space vs. two spaces after a
Ansgar> period.
There are a number of cases where y
I hereby amend the ballot option I proposed using the procedure in
Constitution section A.1. My understanding is that this amendment
replaces my ballot option unless one of the sponsors objects.
There are two changes. The first is the change to rationale I sent out
yesterday. The second is to i
> "Sean" == Sean Whitton writes:
Sean> Could we have a diff, please?
--- /tmp/old2022-03-02 16:48:23.358673871 -0700
+++ /tmp/new2022-03-02 16:48:00.945961500 -0700
@@ -1,7 +1,7 @@
Rationale
=
-During the vote for GR_2021_002o, several developers said they were
+ Duri
I'd like to update the rationale section of my GR to fix a typo and to
better explain the differences between this option and other ballot
options. If sponsors of my option do not have comments I intend to
formally amend my option tomorrow. Sponsors would then have an
additional 24-hours to obje
> "Russ" == Russ Allbery writes:
Russ> I completely agree with separating *unrelated* changes, but
Russ> the whole point of this discussion is that some folks believe
Russ> the changes are closely related, to the extent that one of the
Russ> changes may not be desirable unless
> "Don" == Don Armstrong writes:
>> However, I don't think it should take a 3:1 super majority to
>> change how we collect votes.
Don> I don't want it to take a 3:1 majority to add additional
Don> methods (web based, I'm presuming), but I think not allowing a
Don> signed
> "Don" == Don Armstrong writes:
Don> Rationale: e-mail should continue to be an option for casting
Don> votes even while alternative methods of casting ballots might
Don> also be allowed.
I'm supportive of a change here, and let's see if we can work out
something that we both li
> "Martin" == Martin Michlmayr writes:
Yes, I think 3) and 4) are much more important in hidden votes.
Even without 2, the constitution gives the secretary significant
flexibility in how the voting system is set up.
With hidden votes, several of us believe it is more likely that people
coul
> "Judit" == Judit Foglszinger writes:
Judit> Give the opportunity to vote for secret voting without
Judit> needing to additionally vote for unrelated/only slightly
Judit> related constitution changes; for example for the change of
Judit> mode of voting from email to somethin
> "Pierre-Elliott" == Pierre-Elliott Bécue writes:
Pierre-Elliott> I sponsor the resolution quoted below.
I haven't gone and checked signatures, but unless someone's signature is
bad or something, I think that gives us more than enough sponsors.
--Sam
I wanted to give a diff from what I published as the second round to
what I formally proposed.
The changes should be removal of the text about putting secretary
decisions on hold and some indentation fixes in the rationale.
@@ -40,22 +40,20 @@ Summary of Changes
outcome requires a 3:1 majori
I propose the followiwng general resolution, which will require a 3:1
super majority to pass.
I'm seeking sponsors for this resolution.
Rationale
=
During the vote for GR_2021_002o, several developers said they were
uncomfortable voting because under the process at that time, their name
TL;DR: I propose to unbundle the idea of putting secretary decisions
on-hold from my proposal.
I believe that will resolve Russ's concern.
> "Russ" == Russ Allbery writes:
Russ> Yes. All of these problems are pre-existing, so maybe this is
Russ> really a topic for a different GR.
> "Russ" == Russ Allbery writes:
If other people would like to see the option allowing secretary
decisions to be placed on hold removed, I will remove it.
The specific class of decisions that are related to the rest of the
proposal are unlikely to need to be placed on hold.
Russ> Maybe "
Here's a diff to the rationale section:
Rationale
=
@@ -21,7 +20,7 @@ would require sufficient support in the project but would not
require
another constitutional amendment.
This proposal relies on the secretary's existing power to decide how
votes are conducted. During discussion we r
Hi.
Here's an updated proposal based on discussion so far.
The changes were the ones I said I'd make Thursday:
1) include secretary decisions in the list of decisions that can be put
on hold.
2) Attempt to address Don's concerns regarding independent verification
of the tally and verification b
I hear where people are coming from, when they talk about not wanting to
bundle things, but do not plan to conduct multiple
votes.
Fortunately, especially under the constitutional amendment we just
passed, others who want us to act differently have the flexibility to
argue for that.
One of the
> "Bill" == Bill Allombert writes:
You are absolutely right.
And in fact Don proposes to embody a requirement in the constitution
that would prevent plausible deniability in favor of allowing voters to
confirm their votes were counted.
And yet, we've been living with this trade off for DPL
> "Bill" == Bill Blough writes:
Okay, this message spoke to me powerfully.
I'm now in the strongly supporting this proposal camp, rather than the
hey I think this is a good idea and I'll do the leg work because it's a
way I can help out promote a good idea.
For me, even one person saying tha
> "Richard" == Richard Laager writes:
Richard> Your secret ballots proposal had some other procedural
Richard> housekeeping bits in it, like dealing with overrides for
Richard> the secretary. How do you feel about the consensus on that?
I think we're fairly close to a proposal th
> "Don" == Don Armstrong writes:
Don> Without minimizing the totally unacceptable harassment that
Don> occurred, all three of you seconded the proposals and were
Don> significantly more visible than a voter listed on the tally
Don> page.
My suspicion is that if Debian had mad
> "Don" == Don Armstrong writes:
Don> We should also enable independent tabulation,[1] which you get
Don> automatically when votes are not secret. [Devotee enables this
Don> currently as well, but future non-devotee systems might not.]
I think the following text already in the con
> "Russ" == Russ Allbery writes:
Russ> [*] I do want to acknowledge, however, that having the
Russ> *capability* for verification even if almost no one uses it
Russ> routinely does provide real protection against shenanigans,
Russ> since it means should anyone suspect shenaniga
> "Don" == Don Armstrong writes:
Don> If we make all votes secret we should require that the voting
Don> system used enables voters to validate that their vote was
Don> correctly recorded and tabulated in the final vote count.
Note that our current constitution does not require thi
Russ, and others who cared about the issue. I wanted to draw your
attention to how I'm proposing to approach who runs the vote for
secretary overrides.
In general I'm proposing that the chair of the TC make the decision of
who acts as secretary for that vote.
The rationale there is that they ar
This starts informal discussion of a proposed general resolution to
amend the constitution. I am not seeking sponsors at this time.
Comments including support or alternatives are welcome. I think this is
mature enough to seek review from the secretary.
Rationale
=
During the vote for
> "Holger" == Holger Levsen writes:
>> He asked that in a thread discussing stuff related to the project
>> secretary, and I didn't think an answer belonged there.
Holger> However that thread has 'secret ballots' in it's subject, so
Holger> I still find it very relevant to th
TL;DR: I'm proposing that the way we handle DPL elections today is a
good start for what secret means.
Holger asked what I meant by secret.
He asked that in a thread discussing stuff related to the project
secretary, and I didn't think an answer belonged there.
So I'm starting a separate threa
ong writes:
Don> On Fri, 04 Feb 2022, Sam Hartman wrote:
>> I see two ways of reading section 4.1.7:
>>
>> 1) If the DPL and secretary disagree on any issue then the
>> project can replace the secretary.
>>
>> 2) If the DPL and s
> "Steve" == Steve McIntyre writes:
Steve> Hey Sam, I hope you're well!
Steve> Any progress on that please?
Yeah, I started a thread back on January 29 to focus on the big open
issue we discovered before deciding to defer things in the first round.
I think as of last Friday, we have
ut who it gets
delegated to by default.
I would trust the TC chair with the advice of the secretary and DPL to
find someone to run that vote.
>>>>> "don" == Don Armstrong writes:
Don> On Sat, 29 Jan 2022, Sam Hartman wrote:
>> So, to be specifi
> "Jean-Philippe" == Jean-Philippe MENGUAL writes:
Jean-Philippe> secret vote does not make part of them, if I remember
Jean-Philippe> correctly the constitution and the debate, so the
Jean-Philippe> debate was about intrepreting the text about this.
The specific question that ros
Hi, everyone.
Now that we have concluded deciding our GR procedure, I'd like to come
back to the question of secret ballots that we decided to defer from the
last round.
As a reminder, that discussion started at
https://lists.debian.org/tslilx2fuo8@suchdamage.org
In <87a6ic6wl1@arioch.
> "Andreas" == Andreas Beckmann writes:
Andreas> What is "Russ' proposal"? My first thought was: Why is
Andreas> this making a reference to something from the previous
Andreas> discussion period without explicitly stating it?
You are correct that Russ's proposal is Choice 1.
> "Russ" == Russ Allbery writes:
Russ> Apologies for not having followed up on this message yet. I
Russ> got rather busy with non-Debian things for a bit.
Russ> To provide a status update, I think Kurt identified several
Russ> significant issues and we need another revision.
> "Wouter" == Wouter Verhelst writes:
Wouter> Hi Kurt,
Wouter> On Thu, Dec 02, 2021 at 06:45:24PM +0100, Kurt Roeckx wrote:
Wouter> It was always my intent that the discussion time can be kept
Wouter> alive as long as it has not yet expired, but that it cannot
Wouter> be r
> "Russ" == Russ Allbery writes:
>>> 7. Proposing a general resolution.
>>>
>>> When the Technical Committee proposes a general resolution or a
>>> ballot option in a general resolution to the project under point
>>> 4.2.1, it may delegate the authority to withdraw, amend,
> "Russ" == Russ Allbery writes:
Russ> Wouter Verhelst writes:
>> On Mon, Nov 29, 2021 at 08:55:19PM +0100, Lucas Nussbaum wrote:
>>> Instead of the quite complex procedure proposed by Wouter,
>>> couldn't we patch the DPL's power to increase or decrease the
>>> the disc
> "Russ" == Russ Allbery writes:
Russ> Here is an updated version of my proposal, which incorporates
Russ> the formal amendment to change the default option for TC
Russ> resolutions to also be "None of the above" and fixes two
Russ> typos.
I still support this and my second s
> "Steve" == Steve McIntyre writes:
Steve> Hey folks, I've got something else to talk about
Steve> (firmware!!), but I'll wait until this current discussion and
Steve> vote is finished before I start. Let's not overload people.
would you be willing to let peb and I propose the se
> "Russ" == Russ Allbery writes:
Russ> I propose the following General Resolution, which will require
Russ> a 3:1 majority, and am seeking sponsors.
I second your proposed GR regarding voting systems improvements and do
not object to the minor change Philip pointed out and you accep
> "Charles" == Charles Plessy writes:
Charles> One last question: in some complex GRs there were
Charles> discussions about problems caused by mixing 1:1 and 3:1
Charles> majority options, which frankly speaking I could not
Charles> undertand because I never studied our Condorc
> "Timo" == Timo Röhling writes:
Timo> I must say I find your reasoning convincing. A certain
Timo> stability of ballot options is desirable, and as our voting
Timo> scheme does not suffer from spoiler effects, we can afford to
Timo> keep the odd stale option. Besides, as you p
>>>>> "Carsten" == Carsten Leonhardt writes:
Carsten> FTR, I'd also prefer a separate GR.
Since no one prefers combining these efforts, let's come back to secret
ballots after Russ's resolution is resolved.
Carsten> Sam Hartman wri
Holger> all of this and additionally personally I'd also find it
Holger> disrespectful to hijack/piggyback (on) Russ' work.
I'm frustrated reading this message because it sounds like you've jumped
to the assumption that I'm hijacking Russ's work without coordinating
with him.
I don't thi
>>>>> "Russ" == Russ Allbery writes:
Russ> Sam Hartman writes:
Charles> - About the sponsors, if there are too many, then the
Charles> proposer is more at risk to face vetos when accepting
Charles> amendments. (I write that as I accep
Russ made a final call for informal discussion.
I'd like to ask the community whether we'd like to handle secret ballots
now, or in a separate GR.
The rationale for handling things now is that we can get it done with
and if a controversial GR comes up, we'll have the option of secret
ballots if
> "Felix" == Felix Lechner writes:
Felix> Hi,
Felix> 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.
Felix> It was impromptu. The mail was intentional only in the sense
Felix>
Charles> - About the sponsors, if there are too many, then the
Charles> proposer is more at risk to face vetos when accepting
Charles> amendments. (I write that as I accepted major changes as
Charles> the proposer of a GR option some years ago.) Would it make
Charles> sense t
> "Timo" == Timo Röhling writes:
Timo> I am fine with any name on which the FTP masters and the DPL
Timo> can agree, including the current one. I would also happily
Timo> ratify their choice via GR if they felt that the whole project
Timo> should have a say. What I do not want
> "Russ" == Russ Allbery writes:
Russ> This analysis is very sensitive to the percentage of people in
Russ> the minority who would be willing to delay the vote. I think
Russ> a more likely number (probably still too high) would be at
Russ> most 10% of the voters (a quarter of
> "Wouter" == Wouter Verhelst writes:
Wouter> Can you shed some light on your opinion here? I've tried to
Wouter> build an option that I hope can achieve some form of
Wouter> consensus, and I would like to know whether I have succeeded
Wouter> in doing so. I don't think I'll c
> "Nikolaus" == Nikolaus Rath writes:
Nikolaus> On Oct 22 2021, Wouter Verhelst wrote:
>> I also believe that a ballot with options that were written by
>> people who do not support that option will usually result in a
>> cluttered ballot, with various options that are almost
> "Wouter" == Wouter Verhelst writes:
Wouter> However, the problem I see with strict timings that cannot
Wouter> be extended in any possible scenario is that we may end up
Wouter> with a situation where one option cannot be fleshed out
Wouter> entirely due to lack of time. I th
> "Wouter" == Wouter Verhelst writes:
Wouter> I hear and agree with the argument against such a procedure;
Wouter> having a way to delay the vote which everyone can trigger
Wouter> opens the system up to abuse, which could allow the vote to
Wouter> be delayed indefinitely if fo
Russ pointed out that I sent my message of support for the current
language about discussion timing only to him.
That's not very useful in terms of judging consensus, so here it is for
the list.
Start of forwarded message
From: Sam Hartman
To:
> "Russ" == Russ Allbery writes:
Russ> I've been thinking about this because I like the idea in
Russ> theory but can't see how to make it work in the process
Russ> without introducing new problems including tactical voting
Russ> issues. I have also been wondering why it would
> "Bdale" == Bdale Garbee writes:
Bdale> Russ Allbery writes:
>> The process I'm proposing arguably favors the opposite side from
>> my own in the TC decision that primarily prompted this change and
>> would have prevented the process that indeed happened.
Bdale>...
> "Felix" == Felix Lechner writes:
Felix> The constitution's projection of hardened confrontation
Felix> entails a terrible reflexivity: A 3:1 supermajority leaves no
Felix> gray area. There is no gentle nudge and no room for
Felix> measurement. The maintainer was so wrong, fi
> "Russ" == Russ Allbery writes:
Russ> I don't recall the "when the outcome is no longer in doubt"
Russ> provision having been a problem in the past, so I admit my
Russ> bias is towards fixing the wording but maintaining the current
Russ> process. I'm not sure there's a need f
> "Russ" == Russ Allbery writes:
Russ> Procedurally, I don't believe we should automatically start a
Russ> GR because I think there's benefit to going through the normal
Russ> GR process. For example, who is the proposer of the GR for
Russ> the purposes of making subsequent ba
>>>>> "Bdale" == Bdale Garbee writes:
Bdale> Sam Hartman writes:
>> The math certainly helps. We can easily see that even if we
>> think that kind of strategic exploration is not an abuse, it
>> clearly would be an abuse if so
>>>>> "Barak" == Barak A Pearlmutter writes:
Barak> On Wed, 21 Apr 2021 at 16:57, Sam Hartman
wrote:
>> That's a big jump, and I don't think I agree. At least not when
>> you phrase it that way. Why should my preference matter le
>>>>> "Barak" == Barak A Pearlmutter writes:
Barak> On Mon, 19 Apr 2021 at 16:35, Sam Hartman
wrote:
>> I think we need voting reform around how the amendment process
>> works and managing discussion time ... ... Preferences can be
&g
> "Jonas" == Jonas Smedegaard writes:
Jonas> Quoting Barak A. Pearlmutter (2021-04-20 16:12:16)
Jonas> Maybe it makes sense to e.g. add a friendly notice in the
Jonas> voting confirmation email when not all voting power is used.
Jonas> But there is already a lot of text surro
> "Barak" == Barak A Pearlmutter writes:
Barak> The Schwartz set resolution algorithm is absolutely best of
Barak> breed. But there's an old saying in computer science: garbage
Barak> in, garbage out.
Barak> If we look at the actual ballots, it's really
Barak> interesti
I'm writing to present an alternate interpretation--the one under which
I think our voting system is doing a good job of choosing among complex
ballots in the last couple elections.
I think we need voting reform around how the amendment process works and
managing discussion time, but I am very hap
> "Gunnar" == Gunnar Wolf writes:
Gunnar> I would not like to remove the expressive option of stating
Gunnar> '-' as a synonym to "below all other options".
We are in agreement.
However, I think Adrian has made a point that there are some non-obvious
consequences if you don't fully r
> "Adrian" == Adrian Bunk writes:
Adrian> My suggestion would help people to make full use of their
Adrian> vote by forcing them to rank all options.
Adrian> Equal ranking is still possible, it would not remove your
Adrian> freedom to rank any number of options equally.
I'd
On another list, there was discussion of the DPL encouraging the
secretary to make the vote on the rms GR secret.
I'll let the DPL speak for his own position.
A bit of background.
There has been increasing harassment of people based on what they are
expected to vote on the rms gr.
People on bot
> "Adrian" == Adrian Bunk writes:
I don't know.
I can totally believe that someone wouldn't quite have the stomach to
actually say that they prefer more discussion of systemd.
I actually think 1--- is a reasonable vote.
And yes, I understand you are not expressing a preference between
> "Timo" == Timo Röhling writes:
Timo> * Mathias Behrle [2021-04-03 10:22]:
>> [ ] Further discussion [ ] Do nothing, leave the question
>> unresolved [ ] None of the above
Timo> The way I see it, all these have the same consequence for a
Timo> vote (that is, none of the
> "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 interpret
> "Salvo" == Salvo Tomaselli writes:
>> I sincerely think debian-vote should be read-only for non-DDs
Salvo> because this person is not a DD (afaict) and is just
Salvo> polluting our list with such non-sense.
Salvo> There are non-DD people who maintain more packages and wi
1 - 100 of 371 matches
Mail list logo
