Re: Changing how we handle non-free firmware

[Dr. Bas Wijnen]

First of all, thanks everyone for working on this. It's much needed.

On Tue, Aug 23, 2022 at 10:22:39PM +0200, Bart Martens wrote:
> Do we need to recommend one above the other? I'd rather use some short
> explanation per installer to help the user choose.

My main concern is that users should end up with a good system after
installing. This means two things:

- The install must succeed and (all) the hardware must be usable. For that,
  non-free firmware is often required.
- If non-free firmware is used, it must be updated along with the rest of the
  system.

It is important to me that those things are not only possible, but that they
will happen without any mental effort from the user. I'm all for users who like
to think, but if they don't do that, they should still end up with a good
system. This means the default installer needs to contain the non-free
firmware.

In fact, I am not sure if there are any real world examples of modern machines
that would work properly without such firmware. Are there any machines on the
market nowadays that do not require cpu microcode and do not require firmware
in their network card? And if that is true for less than 1% of modern
computers, do we really want to tell more than 99% of our potential users that
they must read up on the details of their hardware and understand what
"non-free firmware" means, before they can be confident that they chose the
right installer?

My point is: "giving people a choice" has a cost: that people need to spend
time on making that choice. This is acceptable if there is no good default for
most people, or if the amount of time spent is small. In this case, neither of
those things is true: there is a good default for the overwhelming majority of
people (at least I think so, but I'm interested to hear numbers about this),
and it takes serious effort to understand the subject so a choice can be made.

I think forcing users to choose would be a very bad outcome, and because of
that I like Steve's proposal: include the non-free firmware on installation *BY
DEFAULT* and automatically keep it updated. People who are not interested in
studying the details should get a system they will be happy with. Which means
their hardware should be supported, which means the non-free firmware must be
installed. While I'm not against presenting a totally free installer, it needs
to be done in such a way that absolutely nobody will think that they NEED the
installer without the non-free firmware.

I'll note that this argument can also be made for non-free drivers (like those
from nVidia), but I don't think we should install those with our main
installer. The main difference is that their drivers are not as important to
the users: without cpu microcode updates, the user is vulnerable to security
issues. Without wifi firmware, many people cannot connect to the internet. For
many people this means they may as well not have the computer. Without the
non-free nVidia drivers, they can still do everything, but the newest games
won't work as smoothly (or at all). That is something that can be solved later
(by installing the non-free drivers, hopefully after being informed of why
those aren't in Debian). And people who need them are capable of doing that.

Finally, I want to make some comparisons:

1. We don't tell people that they must not buy devices that contain a ROM chip
   with non-free firmware. I believe that moving the code from the ROM to RAM,
   thus requiring it to be sent by the OS, should not make any difference. We
   should still not tell people that those devices are bad, and we should
   support uploading the firmware to the device.

2. We don't enforce the DFSG on art. It's not uncommon that art is generated
   and thus has source code. Or at least that the version that was used (for
   example: a PNG image) is not the version that the artist works on. Their
   "source" version may be using a non-free editor. For code, that would mean
   the build system cannot be in main and thus the package should go in
   contrib. While some people (including me) have in the past argued for this,
   it's obvious that we don't have the same rules for art that we do for our
   programs. While not completely identical, I believe it is reasonable to
   consider firmware blobs to be more like art (in the sense that they are not
   running in our OS).

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Draft proposal for resolution process changes

[Dr. Bas Wijnen]

On Tue, Sep 28, 2021 at 04:11:44PM +0200, Karsten Merker wrote:
> In case there should be consensus about requiring the TC chair
> to provide a casting vote in case of a tie, this would IMHO
> require changing the wording of clause 6.3.2.

I agree that if we keep the casting vote intact, it needs to be a must in order
to ensure the TC will always decide something. However, I agree with Adrian
that it would be better to instead turn the decision into a GR in such a case.

Thanks,
Bas

Re: Proposed GR: State exception for security bugs in Social Contract clause 3

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Jan 10, 2017 at 08:49:56AM +0200, Lars Wirzenius wrote:
> Now, it's true that we track security issues in a different, and
> it's private, which is in contradiction to what the social contract
> says:

It's also a service to our users and free software, so not doing it is also in
conflict with the SC.  Such conflicts are not unusual.  AFAIK we solve them by
deciding which is more important in this situation and doing that.

I do not think the SC needs to contain details on how that decision should be
made for every case.  As stated, this case seems to be a non-problem and I
would prefer to not solve it.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYdIcqAAoJEJzRfVgHwHE6m2MP/jJ19gs3x8XSjgxt/8trhOH3
xd5MDQql5kEfV5UGEv3DZVVh3xj9MiKicRBSsm1c+zPIg7CwBHwSfAP3Ujj+2CkP
YA/TRPvYANzopRuv7VzQ8V1vz9dTZ/WWpkQQZHmx/rLe6sY59W9UBWNbTnb8STAz
nY/r3ZOr0fadsd3nL34Cx9psA+Iz74tIi9a8TsNkzl2GTDgqvXFk9jyHpHmbKyG6
geUE+3ZVWRzZ2S72fFZWA8ZWVngtlhDLPp0mcxyG9+1dr8KsrQNs+/9Asho36tfP
gyjwsb96QSRlv+C93MyaRk/G+OO23Mev4/s4AspuykVt6N/2XZG2SZs20ODoCHd0
odzXV72Dcl50Het3HYd3dCLWs1N/n6Kdc5leFrXZ6757wQjB28bZLuZ1DG6ENfwM
CIdgnPu5pn33tXPVt5k9b0TtJrNoc1FFC9pO7q5fr42BMGwJkj3T3uIRAX8twNwV
lBb12vNP3vRLUIPtSZpFrw007sWjiD+JVHz8YYT1zHA6mjouMlvLtm7ZapizafCD
OBEYIswI9uaqUA5buBbnWnf9kuSFlcJVVIf2O7EHcuRAwuqVU50eeLULSKxXwJRt
wHydafcx/4Y9Ef70lasaI6YFqWVUSw2tnT5N5DDNof9QHfceRwSc+kPggo1nWDFL
PvW26j7mfRb0qsiBYbpi
=dOVD
-END PGP SIGNATURE-

Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Sep 21, 2016 at 03:27:19PM +, Anthony Towns wrote:
> One of the benefits of eventually publishing all discussions

You are not suggesting that we should publish posts where their author
explicitly says they should never be declassified, right?  So "publishing all
discussions" will never happen.

> is being able to prove that you *didn't* say things

And so nobody can prove this.  And even if all of -private was declassified,
then it would still be impossible to prove that you didn't say it in a personal
email to some people, or on the phone, or ...

> When I joined Debian I endorsed the social contract [0] which said
> "we won't hide problems". I think folks are renegging on that ideal,
> but even if that's what the majority decides, I don't think it absolves
> me from my commitment.

I like your idealism; I'm an idealist myself and that's one reason I like
Debian.  But I disagree that this clause implies I should not have privacy.  I
should not use privacy to pretend Debian is better than it really is, sure.
But as a human, and feeling a bond with my fellow DDs, I want to be able to
have private conversations.  I do not see how that is "hiding problems".
Perhaps I hide my personal problems if I discuss them with my friends (on
- -private), but to me the social contract applies to my Debian work, not my
personal life.

> So if the proposal that attempts to deauthorise
> people from releasing their own posts to the public gets on a ballot,

I haven't seen such a proposal, and I cannot imagine that it would win.  Well,
unless you are talking about your posts quoting others who don't consent to
their words being released.

> I would prefer some sort of middle ground that has some consideration for
> people's desire for secrecy; but I can't see that happening at this point.

I'm not sure what sort of thing you are referring to, but doesn't one of the
current proposals do what you want?  If not, please write your own proposal!

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX4qtLAAoJEJzRfVgHwHE6saAQAJbbAp+wwk9Q9l41kEgZoVM+
uH5WGafWu+XxAD/dVDEnJ8xgNK67nKCffUhL3WA3ykZdTZUQ03xzdl+lxFkGM8GL
pPDXnIo2N39xE2VU+t7pEV7FVDWCe2J7GOws5zGf+OHa5N09GVHE/syHSTpDqBXS
ZZq0VzRBo3WvAhzDUfDDvxA/ylwGyLn/1imL60s8y4lbaAgv3D/gidHB9V1un9gm
3S1p1ufvn44W2YlugfuP2aeh5LnpJtoNgyshvpoxpiN6G+r7vxUXMmBtLwblgXho
kWTvMJw5UfjO83y40TAeDbQ2qtSK1hwr7Ac21tSV2HosT47XXs0ffBrf4yEXwars
PMyv+1ysJVPffA+cRVkGQNM6g+bMkmoB1BADfYwq7TtqY8UI/cCG7Bl1VwzXfNTw
m/nBagMvCtPK18yr7ll/di6xJ4OmkcfrRhVxQ4zXo8QBhthqCfpa2p3Fgbm8BrSu
zaygQIK+3Z2Z6PZpr/gwX00mBMTnpOEMR3FJW5RfTP9hVbXP02XeJ/uKThY4dPlB
j7aM7AplfMaVzQzH/05E/lRiXi2XqI+xfO8lQfOsWefS4LfamPSuWJpi4Bf4GIgj
6YuT8QsYUv3NliLpyWWKFCtJcYi4eBU7ZSiE9hlDOATqTtXcQMBVPA7C77oinrtI
pg9T6cNyP1U43NlWFBt2
=Gjam
-END PGP SIGNATURE-

Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for the reply.

On Wed, Sep 21, 2016 at 03:07:43PM +, Anthony Towns wrote:
> ] This list has hosted a number of significant discussions over the years,
> ] including most of the discussion inspiring the original statement
> ] of Debian's Social Contract and the Debian Free Software Guidelines,

Those seem like they have actual value.  But in 11 years nobody cared to do it,
so perhaps it wasn't all that important.

> ] the reinvetion of the new-maintainer process, debate on the qmail to
> ] exim/postfix transition for Debian mail servers and more.

I don't have a problem with such discussions being declassified, but I also
think there is near zero value.

> ] This trend continues today, with the six months just past have averaged
> ] around 190 posts per month.

Nowadays, I don't see any discussions of the type you mention above (which
shouldn't have been on -private, at least not by our current standards).
Counting posts is not a good way to show that they are incorrectly posted
there.

(But again, I do understand that you can't just say "this post here".)

> Since then there have been other important discussions; ones that come to
> mind include the actual and potential expulsion of various developers,

I thought about that, but it is an excellent example for something that should
definitely never be declassified, IMO.  Not unless the authors and the subject
all agree, so there it's even harder than for topics that aren't about people.

> how to deal with money in various ways, and relationships with various
> companies including special deals offered to DDs.

Of the posts on such subjects I saw, a good reason was always given that they
were posted to private.  Or they were quickly moved to a public place.

> I don't think it's hard to come up with ways in which the above *could*
> involve DDs acting in their own interests rather than the interests of
> Debian's users and the free software community.
>
> Making the discussions public is a way of demonstrating conspiracy theories
> along those lines are unfounded.

Wait, this whole declassification is meant to disprove conspiracy theories?
Not only is that a waste of time (those people don't need facts to believe in
it); it's not working even if they would follow logic!  How is "we show you
some of the things that we didn't show you before" in any way proof that we
don't hide evil things?  There are still parts of -private that are not
published, and aside from that, what's stopping us from using a secret
list for our evil schemes?  Or claiming that we publish all without actually
doing it?  Also, don't you think the evil people wouldn't just say "none of my
posts may ever be declassified"?

The only way to actually demonstrate that is by denying every Debian
contributor all privacy.  I don't think anybody would advocate for that, so if
that's the whole point, let's forget about it...

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX4qdSAAoJEJzRfVgHwHE6lGEP/i+VOt4beF5GVLktMOHph/o2
F12OBBvjQMfWg+qELRn++DRfb7jHDiq5tFPQrajvs6yHeldk7C+gHy68OagDYzi2
4pKpr8EhOY26LLZ2AstM0kWy/TCDpSa9m8c0rx4WRyres408Ayb+4mKyr35icZUc
Y85CM6MnpEUFKFq6MUr1Ylg42It++1I1VfYpysytVqhJlGcsr5S4c4GgtfxsYuGN
/8BbMmuT4HFBtx3GuCU37sQMukzUTaH1n5+1qm2pq1MDfbESEGu5LGcRazrg8CG4
xBv3EY/0I3bzL3qVcMLIf52390MjZgyAVI5rMcfMQsp7tQKQW3JSXjeZNPjYuCRU
oS6o3JcZWqZQPNd7v/JuVpNAonxsxmIdK5utDSpgBYF3FEIN8aakDFG7vt8dkiWx
sxRCiHAmXfliYuMKdR2uSrQ7ShaPODpE254/XojrEjVZ3sAXhPJ5+9lTsSRioT65
P7aPBf424yUtLQG/tBO6LlNkGSRJ8dDC4JJFqwSsyqTEcYr8H4g1UniShiE1z3kh
XUIdP+/VnJBmUI0LSEAjEXcMQIOjH3S1BfRhtbpXiUzIuATn6Kms0IEjPT0YvMWX
tN7kGFGjddhPhYKj1+LwUXwIHsYdLP0Sckni/33Gfdzqm0FhefJTuaq6mUSVhnhQ
tkEeic2IOkFKzNsF3sfP
=7n/w
-END PGP SIGNATURE-

Re: Proposed GR: Acknowledge difficulty of declassifying debian-private

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Sep 21, 2016 at 03:19:57PM +0100, Ian Jackson wrote:
>  Iain Forbidden.   Difficult/unclear.[2]
>   New GR would be needed   New GR probably needed.
>   (or active consent
> from each author).
...
> [2] Iain's proposal speaks of "archives".  That might mean only things
>which are archives at the time of passing of the GR, but IMO the
>more natural reading is to include all archives even those which
>might come into existence in the future - in which case listmaster
>is prohibited from setting up a declassification system which
>applies prospectively.

Yes, I think it is very clear that Iain's proposal requires a new GR if any
past or future posts are to be declassified without explicit consent from the
authors.  Does anyone else think this is not clear, or open for
misinterpretation?  If so, please propose alternative wording that would be
more clear.  I think this option will win (it has my vote, too), so I don't
want it to be unclear.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX4ps/AAoJEJzRfVgHwHE6f+EQAKFf/xs17VpO0CmhNWxchgCl
bmfQlnwi+fbZm1b1AuSrgUTg5jrVrLHuUxDw9d/wqswfLnJyfRqlW5J5LMxUKMwb
m6c6EesceEcvujtvmD3QJt1GojcltaiIfihEoeoe/53VAcNqWnF4Igxgij4bVTYF
01XBygvbWV+s53SoF5B9Ex4L+UgF7sdmJ9ei+YWssfNcHRwMVTh+7tZ65RLL1SEO
eIn/LyBYxDAxKOp7wD8z5EQaLIvlVGbhrBUxcUCC27IH70kkKimkoZWAiCDwZ805
aTJuL/ML3GtfEQF8oitGWfEruLvLuEUOiAX9OeiXdSeZnRtCP0ZrPAmKgHhtNeKd
tkaZabSfj5ds3XxbDD7YxcTXJTBIFDnd+urYIKkMfpG3LPWa2WeSo+RMkIS463Hp
1ZG1vY7WtsnE9YMjIo1FO/ItpNzSFCiraPwzOkC5zQEL1+RNfYjBdixS/F8Oc+cA
WZCQP4Onffjn3hzWcKPd3oHme6veRpMC4VnulAwujMSoRtWULvTv5A//L1IUzmYS
mvGgFNnO4qHivNyqOMYuDlcjadMQaR+1VNvj/Rb12Cz7R2dwUYIrItpQSx/Rz7St
xsggHYL3WXMUdZKAO9tcW9/lDDcQuyjAzbo1D2DGzcCx8e0bvL9lgpK85QrVXRal
ma5aN0fG5JepTIsyzPfH
=pRGz
-END PGP SIGNATURE-

Re: GR proposal: give up on declassifying debian-private (Re: General Resolution: Declassifying debian-private results)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Sep 21, 2016 at 02:57:21PM +0200, Sven Bartscher wrote:
> On Wed, 21 Sep 2016 13:53:28 +0100
> Ian Jackson  wrote:
> 
> > I think it would be best to seek further sponsors for my proposal.
> > If you like my version, or would like to see it on the ballot, please
> > second it.
> 
> Seconded

I also second this amendment to be on the ballot, even though it will not be my
preferred option.

Thanks,
Bas

> > Here it is:
> > 
> > > Formal proposal for amendment to Gunnar's GR: delete all, and replace
> > > with:
> > > 
> > >  Title: Acknowledge difficulty of declassifying debian-private
> > > 
> > >  1. The Debian Project regrets the non-implementation of the 2005
> > > General Resolution titled "Declassification of debian-private list
> > > archives".  That General Resolution is hereby repealed.
> > > 
> > >  2. In case volunteers should come forward: Permission remains for the
> > > list archives (of any messages, whether posted before or after
> > > this resolution) to be declassified, provided that the
> > > declassification process is at least as respecting of the privacy
> > > of posters to debian-private as the process set out in the 2005
> > > General Resolution.
> > > 
> > >  3. Furthermore, the Debian listmasters remain empowered (subject to
> > > the usual consultation processes within the Debian project) to
> > > revise the rules governing the privacy and declassification of
> > > messages to -private.  This includes making measures to make
> > > declassification more widely applicable, or easier to automate.
> > > 
> > >  4. But, any weakening of the privacy expectations must not be
> > > retrospective: changes should apply only to messages posted after
> > > the rule change has come into force.
> > > 
> > >  5. In particular, we reaffirm this rule: no part of a posting made to
> > > -private, which explicitly states that it should not be
> > > declassified, may be published (without its author's explicit
> > > consent).  This rule may be changed by the listmasters (para.3,
> > > above), but only for future messages (para.4, above), and only
> > > following consultation, and only with ample notice.
> > > 
> > >  5. Participants are reminded to use -private only when necessary.
> > > 
> > > -BEGIN PGP SIGNATURE-
> > > Version: GnuPG v1
> > > 
> > > iQEcBAEBCAAGBQJX4Vn5AAoJEOPjOSNItQ05vFgH/29lNK5S6bUo1mXZhau74UP5
> > > 8PMCDwEUa7rcYuKefJH4wxvLxQM5FBL8kg72Y4gvr7unqE/sA5HIDsV0pC3EbLZN
> > > c2dwmSTrJcxcpST5GI5nfDrUoiP3Y4RMmeLOR97ugHYXxofzakn2XzWMFeoZfChC
> > > gu/gb09n6wNkPTvO5YBw2Ve/Soud5TUD1RehK+E2z1d2hvesekRG3k9cWVuxxoj7
> > > ljfBpTuNpsnWzbItyhequ+U57tsyS92FWGgANzpQmO+GhhZpZlFImKlAJN4Vi0Dl
> > > jVrDD24EKjKOxIIMxU7448ciITXeTsnfTgylfX9zrzAKfwa7gWPnbWrGNF0E9us=
> > > =/vLH
> > > -END PGP SIGNATURE-  
> > 
> > Thanks,
> > Ian.
> > 
> > -- 
> > Ian Jackson    These opinions are my own.
> > 
> > If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> > a private address which bypasses my fierce spamfilter.
> > 


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX4pkuAAoJEJzRfVgHwHE6tREP/iUJiJiNYR9v+N4eCoRBABIP
PuFurACi7nIiClBecCNXQZmW2UbR0kTR/fc6OgZ4Ujlom+uGZEfKryRYMnNqj1E3
9HJUds7hrdibf6+B2KsnTkGBkfaGrugthBIRivRWa8qXZZk+CMDBGD8NCosvoOR7
5EmxPrM3iWgY698YSr5yleD6Zbi1f/cP6sv8u2hm+DbYXIMFpC3m4+s1tA1fzCwi
20Y5cMdEipb2G8suZZJ5KDQI3h//6UYfQdLr74RyLExqT++UQzXN5JUTwo1kmQ5B
Zl+XXSSg+9BFoKMc1nCCrs3oPinkePg3+RLfxFycDR/O4Dt9f42clmvpQ+V3qK3I
FwIUc8w8NAUWM23W+8AhOgWsx7oi0VJcPvhgD5MXdEi75tcNV5NxVoLQ/XwSjuVY
K1qQLzNtLzmhBrEu8ygSMPgH89vPDBnFY2SegD8Do3ofSrQgprJ21zCB3+KmAMpl
hwaqDcF3wuvLLA7b4kUWCCKDsf8U6krIU8RzzedInZChGRKtBuUcCyRewkQVgKST
8VcP4wxBIuVi3JzmZkM/M1+GLPI3D+pfOwPjjUwyZ38UFUIrpeZRD9SpqAPAsMJa
QJMttq4sq/j6dTdoMdI315qX/XOobWNarNO4SaTaRnqVQwCr2ccUl0JuPG/N+Gua
oWhbAo2p0quDI8x4CHaO
=0er0
-END PGP SIGNATURE-

Re: New amdendment proposal (Re: Proposed GR: Acknowledge difficulty of declassifying debian-private)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Sep 21, 2016 at 01:47:41PM +0100, Ian Jackson wrote:
> FAOD I assume that this is to be taken as an amendment to Gunnar's,
> which replaces the whole text with your text.  (Otherwise it would end
> up in a separate vote.)  On that basis,
> 
> Seconded.

Yes, I was seconding it as such as well.

> >   2. There shall be no declassification of any portion of the
> >  debian-private archives, except in the following circumstances.
> >  2a. Participants may declassify their own material.
> >  2b. Participants may declassify the material of others where
> >  consent has explicitly been given by the authors of all of the
> >  material being declassified.
> 
> I do think this is unnecessarily verbose.  2a is entirely redundant
> because obviously if a participant declassifies their own material
> they do so with their own consent, so are permitted to do so under 2b.

No, it isn't.  That would be implicit, but 2b requires explicit consent.  2a
makes sure that you don't need to write "I consent to declassify my own parts
of this".

I agree it's obvious, but technically 2b would require that if 2a was missing.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX4oKbAAoJEJzRfVgHwHE6Zj0P/3scJbVr6+wPrMOWHm5aJ1va
z9ftVeyl06iE3KlN9lfPJZIXBsmJO52wSQyoWpYzxbh9h2zinQlIeVCXD91zoVm7
1Qy0WvyD6ByXfP5wqpDnQERYc+9021+4ipLp4qOHpT3WJgzze4F9YxIY3N8NFtQB
1CCIIsMBZuaiVYfHp7Zn2Pr37wh76TXlOWwAN5H60LWCoUOKnl4SH17YAJlzaR/S
34Qh9hXc80ivITbLuoe86jyH9d8xHPIZ7fFzwWMCg1WB3RBS1i7jw4hYTkL3yuuS
bPWibz1jhgiLqYnBAnUY2xlwzshotu9e5DojgWCs4OcF540KlrDzeXKq0aZTcDlN
UDySPcv9sKByHjTNVmo+/kWjyrrixOfDVReOwPGEkFauZEIU2cz9SM9CvehV5lAG
vFiwR16MNQ/lmyOL2vzOuHFr38/XCP4FkaIKh1HWWXuYSwXXqHw1qOBLHE0Hkl2D
LTdm/J6MFofEU3Oc/cgxuF1ncDAQs/SdZwBnvMNpJPvOsVBupTv+j5J/yaj4oI20
c60voSnhaplIy4SgRN4NsfOc7li2pfBVQTqmKbUqFMos0KgHfRNFitUCPIioR/sT
FlbnrprY1bwzJ0c3UXiFWQOW/WSUFf9UBlCxKKj//ExXSHA06u3TacTgwZn67/da
pV4ojqTvM3fU0AL+RubI
=iamI
-END PGP SIGNATURE-

Re: New amdendment proposal (Re: Proposed GR: Acknowledge difficulty of declassifying debian-private)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Sep 21, 2016 at 11:01:50AM +0100, Iain Lane wrote:
> 
> 
> Title: debian-private shall remain private
> 
> The text of the GR is replaced with the following.
> 
>   1. The 2005 General Resolution titled "Declassification of
>  debian-private list archives" is repealed.
>   2. There shall be no declassification of any portion of the
>  debian-private archives, except in the following circumstances.
>  2a. Participants may declassify their own material.
>  2b. Participants may declassify the material of others where
>  consent has explicitly been given by the authors of all of the
>  material being declassified.
>   3. Participants are reminded to use -private only when necessary.
> 
> 

This looks good to me.  Also, I second this proposal.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX4mq3AAoJEJzRfVgHwHE6e1MQAJtnuO9FCaJZSHso+1LU2xFg
Zk1rFDqmGbCp8yV6AZq+LBswPe2HWpyPlwBqWSBXyw6mzjkQEU5IwOIiMqFTjrFC
ZaSN2tBJS9rlPpQTWe5uJFh1YDjnzDQSWS84t+8pRapI7eIUIjhw5+Bgi53m29lc
jBZtytJBSlJJoNFDNOcHdu540uA7UkfQ66b4nHQghHRqyg8gX+KIOEp82wYL/0CM
jHusw5GYekAdQXh/yyX9eM5bnStdY5cpoaZt5TP61mW4E9d586yeLYbVpzPTPYLM
HVrydt+lzwAVCNS5swfROTRA9a+EqDBPLQg6C1cm65zBezY4LlxLfuP6IS47uZqJ
kOfKqYTEhE1GI9V7/1xzD+Gnnu1CgSBF/gPxF02De/K4I33DMfTQZ/CCUEx2DnMZ
/Ik1M1SeE13HSidHET2qROvYW0UhuTlcPuop5BR4k9V8HBwr1vM9MEwSC5IkJFoz
drNesCVQRGKNEW/I2xuK7kp2AKM/tHN69L6Vv9v+G6lWBKFSaz8wnUqAG63DBNb7
zNd8QXNLqHhAah3MeK8TnZhVrlQxQ/zyUTkvJlcKru+5OgX2BKPihM8UJhUoxOif
Fo3Rkf8RgV9MYGmb39ykNQc8uAIdEpnje19QVbP4k9g/Pc7wRwcw+XYiG89ko/QI
Rnbxs4E/4gtszaQ4JtA2
=Zlks
-END PGP SIGNATURE-

Re: Proposed GR: Acknowledge difficulty of declassifying debian-private

[Bas Wijnen]

On Wed, Sep 21, 2016 at 09:55:52AM +0100, Iain Lane wrote:
> > This message fits your description ("the author is quoting only his or her 
> > own
> > text"), and so it would be allowed *for anyone* to declassify it, without my
> > permission.
> 
> Are you saying it should be 's/quoting/declassifying/'?

No, my point was that "the author" seems to refer to the person who wrote the
email on -private, not the person who publishes it.

But given your rationale for the clause (which I agree with), the clause as is
or with your change wouldn't be enough: you want the person doing the
declassification to not need to explicitly consent to the declassification of
their own parts.  That is also true if there are parts of other people
declassified.  Hence my suggestion in the previous email.

Thanks,
Bas

Re: Proposed GR: Acknowledge difficulty of declassifying debian-private

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Sep 21, 2016 at 09:14:00AM +0100, Iain Lane wrote:
> On Tue, Sep 20, 2016 at 07:14:39PM +0200, Jakub Wilk wrote:
> > * Iain Lane <la...@debian.org>, 2016-09-20, 17:54:
> > > There shall be no declassification of any portion of the debian-private
> > > archives, except when the authors of all material being declassified
> > > have explicitly consented,
> > 
> > So far so good...
> > 
> > > or the author is quoting only his or her own text.
> > 
> > Huh?
> > 
> > So it would be okay to declassify someone's message without their consent as
> > long as they didn't quote other people in this message?
> 
> I'm trying but I can't understand what you are trying to say here. Are
> you talking about leaking the fact that somebody replied to your own
> text by publishing their mail with all of their text removed and only
> your own quote remaining?

No, the problem is a message like this:

- 
From: Bas Wijnen
To: debian-private

Bas Wijnen wrote:
> This is very private

Yes, I agree.
- 

This message fits your description ("the author is quoting only his or her own
text"), and so it would be allowed *for anyone* to declassify it, without my
permission.

> It is there because the "[s]o far so good" clause contains the word
> 'explicitly', and it is absurd to have to explicitly grant yourself
> permission to quote your own text.

That makes sense.

> Feel free to suggest some alternative wording.

The person declassifying the material does not need to explicitly consent to
the declassification of their own portions of that material.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX4kiQAAoJEJzRfVgHwHE69IQQAJLXHugjJDqdSRsKUtYpyMLo
h1AyD0HCvZmr6MMDlZ0DgspnnZnsO0kAZjx1+NFstr4ikWgTdBllrqIXhPhOQ+Va
KvK5vNOCtHnSVkK1ZMx6g1f6Wn2A7Lgl+GDmhv6TZ3UYNZ2qTZZNdoNPzwLs6Lof
DPeBawB8VaM92t+AE/mZy4Sn/M1snK3VobD+JerjmA1QdSfR0cQtxnNU27Y/Ulb0
Cx8fjCDB1b0YWAGRy0FkojY/Zsy0x5AO8ZjQ1GezkEJMpjLeZqiXTwxTCT0MnLva
NoZPePoPLD/u5Yt3pWQ5oHFOraFXrd7PiXopbe53olvb6qgwNK+UxcxHAk9zsvT3
UH/EEnFVoNKWms8Hhe3BLwRr1bwQSam3L+uKKh++AQpcopEv3rwYZRCEeQFCzfV/
/0oYp56dqokXg+Aw0ybIEUTnk1BAmrKxGgm33c9xmuGm5pL8m0l6vVZBxfPRa7l6
JbaPHwhT8zptiUAbcCpQDGF/UEXbKIerq4H2ZT6KN6WUXmhjUix5cnt32vh6DjyR
aBeXgdbjZJwrbcaYUF4UQMOxZv76j77kIhI8vagaCF3YM73HlHEodPj3BgH8IXXc
Ug7Mkl63K+1wXnk/xN14Jp7kB7xfkGLR+MIsDWmM2kixIj/7E8BxdHNTU4Khp0LZ
6X18ZKlKIeVL89nk1wKO
=2XDS
-END PGP SIGNATURE-

Re: GR proposal: give up on declassifying debian-private (Re: General Resolution: Declassifying debian-private results)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Sep 20, 2016 at 06:06:09PM +0200, Ondřej Surý wrote:
> +1 to what Holder said. I believe it would be better to have this GR as
> simple as possible. And get into multiple options later if FD wins even
> this.

That is not how Condorcet works.  Because it's a ranked system, it specifically
finds the option that is most wanted.  If we would vote on the options in turn
(and stop when the first is accepted), we'd find any acceptable option, but it
may not be the best.  There is no harm to adding options on a ballot; votes for
that new option don't influence the race between the other options.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX4YRHAAoJEJzRfVgHwHE6uH0P/1P2c2obzFhUSH6DvtRyUy7R
IkCrCoXanzjekykuvK4yuwswD81svhMU7IjQ2QhgAfbcudZ4CE997jwb62Zq/2jM
oWn15SCfJERWw+wLdW50aDqwE3wmVZOYok/KRM79UIf9hRI+ABT5taBrk5rMnrIF
V4Je6GeqJfvTCgkR9RDRcsaTl849t5TkdocfilKqdiUYnlTdwvZOesKAO21g3wy7
CNtBNgWypQPl2MeY43bFaXaLuHKoYLmIVPzOmNHzku6bR+9rf0DZ2Y4pfkhQhNhF
c++tSd4Ri4TF5AZx0TD1TgopLFYMaRzcLfdo51NNvbQIyXW6OEd0GTse0syto719
mZKBZX9RsvYntAMWJM7P265l5jUCx49d7DKnCEhZtdH2gwSIXQUrJaxgqsSVYuRd
NIbHXcyg/prJlJWNupOnPSdf5mN2Z2T6Eb8IugCzmq+vgU8ib1Jc9960Aygke++y
vauv0a1CQ5fVu7cfiNr820B8veYk/iQlG3P/56nVCxYDCjA0ENVh2a6r9BT2HW2d
aps30SDnM0e9CkuMS1aENmi7f8RB5wq6fYlBg/OL83th7ogteFMmINtFwJeBAha2
kUpfn1JbwsFn9QRKd9P/Q5OsJApFMnzzodyU59bxBbEuvjIsSd5z8H+8q126bot5
He2ySeX2IN4GpTUTKKsf
=9LPx
-END PGP SIGNATURE-

Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Sep 16, 2016 at 08:27:13AM +, Anthony Towns wrote:
> > I now also tend to think that we, as a collection of individuals, also need 
> > some sort of "safe space" to discuss certain things, that can't be public. 
> 
> FWIW, that's pretty much exactly what I mean by "don't care that much
> about transparency".

By that definition, I think most people don't care about it.  I expect everyone
at times wants to discuss something privately among friends.  And while Debian
is a very technical project, it is also a group of friends, and that aspect is
important to many people.  If you say "That's not what Debian is meant for, and
we should make it impossible", I strongly disagree.  While it probably wasn't
intended, it being a group of friends is very good for the project and a
private communication channel strengthens this function.

> ie, sure you care about it -- and don't get me wrong, that's great --
> but you're not really that interested in going much beyond what every
> other open source project these days does.

Yes.  But Debian does request that -private is not used for technical
discussions, and IME when it is, there is either a reason for it or there are
reminders about it immediately and the discussion is moved elsewhere.

Which leads me to a repeat of a point I've seen before (and I didn't follow the
entire discussion, so I may have missed an answer to it): are there any
examples of threads that the public would benefit from if they were made
public?  (Obviously don't quote them here on -vote, but you can talk about what
kind of messages this is about.)  I can't think of anything for which all the
following are true:
- - It is a thread on -private
- - It does not need to be private anymore
- - There is value is making it public
- - It is not feasable to contact the authors

If nobody can be bothered to contact the authors, I'd say there is not enough
value in making it public.  If you think contacting the authors is too hard,
and want to write a program to make it easier, nobody's stopping you.  And no
GR is needed for doing that.

However, your plan to automatically redact emails sounds dangerous; I would
rather see that any email which contains parts of classified emails remain
entirely classified itself.  The risk of accidentilly publicizing something
that shouldn't have been is much larger than the risk of not publicizing
something that should have been.  I believe that especially because my estimate
is that almost no email should be made public.

> Pretty much all those things are or were hard and people will give you plenty
> of reasons why you'd be crazy to do any of them.

Sure, but those all have value.  They make the technical side of the project
more accessible to others.  Making parts of -private public will do the same
for the social side, which has obvious downsides (it makes it less safe to post
there) and not really any upsides that I can see.  Theoretically it could, if
we would be abusing -private for threads that don't belong there, because it
would limit the damage of that abuse.  But that doesn't happen much, and those
threads usually migrate to a public list soon enough.

Perhaps for some threads an expiration date would make sense.  However, that is
rare and it would be much easier to just post a header to the first message of
such a thread, that it will be made public after a certain date; perhaps add a
marker to the subject as well.  Then it's clear to everyone that posting in
that thread is similar to posting to a public list.

> > "[...] We promise (and have all members as testimonials) to restrict it's
> > usage to topics that really need to be private"

We already have that in less strong terms, and it works fine as far as I know.

At least I cannot think of a single message I've seen on -private for which I
believe there is value is making it public.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJX2+V0AAoJEJzRfVgHwHE6GlEQAIEnrOLELMih6Gz6sV6b0aJp
sDFXg54eByU1INreFAvkvK5HG3qrYFym/h4Yx9/q1NAwvST/LJFCCjcoZoQMyNw4
fnLAaRR+YkUF4T88jEqX4IS9PCGFi6EtJOki/2O97gBYkyhIWPEaH/6mMcYGVg4A
BNkw7cRuu+OvsygWEC1nulT45Wh4ml71DMQesTOL1WFw9pycPt+d3TubGBYRgpsy
tNCdc8HbEC9C3DEh6e+o5K3DdRTabGkDEJWWsXUrWMuGp91zhF0X3iV0V6QlRpzJ
JjYo6kAhhj34wc+8jMeSCLw4UGHEqsq4oKvSbtW7/ZHDvEH9yjathiy5YJje48A2
PD2KrZuV31viXiUtNWDyO7wh5W1xkepFoVBFl6rx9P/aFMvQ1/dJ39q3YFJHiWKO
sRWTFc9655rnIvtwQ2D5lZxycVmZzKYTep8aXTywDfxsZWjJaRtk6K9U7PX2S78H
DBM/0kyRcw4A7FNM7qxpNnejFaQyictgYdqPXot52+0s0v3eclkyNBi74VuLI9b0
JVI2ztnCUxtowmZmXCHCtryacqQ2QvzObfjc2d6myUAwIlJeSNz5K+QJYDFZb7pb
gxjgfnDPD9GhQXr32wHhb3VP211RmIGVfnqdhj9AHVZcYtiUQCCufO7HGOpnaGb8
Fh478HULsWXSRPJGQEhr
=4F/i
-END PGP SIGNATURE-

Re: Q to all candidates: dropping SC §5

[Bas Wijnen]

RMS originally worked on a non-free system when building GNU.  He has
decided that it is possible to run only free software (and shows us that
it is true), but not everyone agrees that it is realistic:

On Mon, Mar 16, 2015 at 09:37:33PM -0700, Russ Allbery wrote:
 I'm particularly concerned about keeping Debian a viable distribution
 for enterprise and large-scale server deployments, where, for better
 or worse, a well-integrated way to add non-free firmware is simply
 mandatory in practice right now.

On Fri, Mar 20, 2015 at 06:11:34PM +, Neil McGovern wrote:
 I would love to run Debian on all systems without the need for
 firmware on open hardware, but that day has not yet come. Until it
 does[0], we should keep section 5.

This sounds reasonable; just like RMS, people and companies need or want
to use hardware that is not supported by free software.

Everyone seems to mention firmware; I don't hear anyone saying we really
need to support games with non-free game data, or shareware programs.
And I agree.

So to the candidates: can you please let us know whether you would be in
favor of restricting non-free, so that it will only contain things that
are required for making hardware work, and for which there is no fully
functional free alternative?  If not, do you think restricting it on
other grounds is a good idea?  If so, which criteria would you suggest?

This is also related to Paul's point:

On Tue, Mar 17, 2015 at 02:16:09PM +0800, Paul Wise wrote:
 Add an extra component that d-i could add to sources.list when
 non-free firmware is needed, instead of adding all of non-free.
 
 Likewise for drivers, GNU documentation, the web, tools for external
 APIs and other common categories of non-free things.

(Aside: I like all the ideas in Paul's mail, but this one is relevant
here.)

Would you be in favor of such categories of non-free, where we can
perhaps include some of them (firmware) by default on installation
media?

Thanks,
Bas


signature.asc
Description: Digital signature

Re: done with consensus decisionmaking, war, rearguard battles [was: Re: REISSUED CfV: General Resolution: Init system coupling]

[Bas Wijnen]

 I ask for is indeed available, a link to it is
very welcome!

  And not just from Ian's side: the pro-systemd amendment in the
  current vote seems to say we demand that you trust everything we
  do, and we don't trust what you do.  When I first read it my
  reaction was Woah!  That's a declaration of war!  How anyone could
  think it would be a good idea to include that in the amendment was
  beyond me.
 
 That was my initial reaction as well.  Then I saw the bitter rearguard
 battles comment, and realized that if the GR doesn't actually make a
 decisive statement with a strong air of finality, this issue will just
 keep going on interminably, preventing people from actually getting work
 done.  If this is going to get all the way to a GR, let's have the GR
 actually *work*.

A GR that goes out of its way to *hurt* people can do only one thing:
drive people away.  While that is a way of making things work, it is
exactly what you blame Ian for.  I would be extremely disappointed if
that amendment is voted to the top.

 I'm quite sure Ian wants peace as well, but only expects to have it
 when all of his opponents are defeated.

Is that unreasonable, if his opponents want to destroy Debian?  I'm sure
he'll be fine with the people surviving, and perhaps even contributing
to Debian.  But if he thinks they are trying to destroy us, of course he
wants to stop them.

 See the issue that started this mail thread, regarding bitter rearguard
 battles.  As Sune said, I don't think it's reasonable to assume good
 faith there and pretend that was really a oh, other people will
 probably keep fighting over this;

Actually, that is exactly what it looked like to me.

 besides, if it was, it would have applied just as well to both sides.
 (Unless Ian is specifically suggesting that the anti-systemd folks are
 less reasonable and less likely to actually accept the result...)

No, the other way; the pro-systemd people would start the battles even
after they would have won, is what I think he suggests, and given the
history I think that is a reasonable guess.

   We clearly have a pile of people who want to discuss and deal with the
   init system issue, many of whom are still capable of productive
   discussion and consensus-building.  Many people are actively developing
   solutions to make the situation better.
  
  Such as we as TC want to write up a statement; I'll do the work?  Or
  is that an unacceptable way of forcing his opinion on others?
 
 we as TC want to write up a statement already implies that most
 attempts at productive discussion and consensus building has *failed*.

Which is true.  And the rest of the TC agreed with him.

 And even then, I expect the members of the TC to actually engage in
 productive discussion and seek a consensus.

So why blame only Ian for not doing so?  In contrast, I think the
discussion was so short because there was consensus from the start.  Ian
suggested to write up a statement and everyone agreed (yes, not
protesting when Ian says I'm going to write up a statement now is
agreeing).

On Mon, Nov 10, 2014 at 12:21:50AM -0800, Bdale Garbee wrote:
 Bas Wijnen wij...@debian.org writes:
 
  The only problematic part I see is that he gets carried away at times.
  That's a very minor issue, and I forgive him, as long as he isn't
  insulting people.
 
 He has certainly insulted me.
 
   https://lists.debian.org/debian-ctte/2014/06/msg00040.html
 
 If you don't know me very well, I suppose you could be forgiven for not
 realizing just how deeply insulting I find the assertion that I have
 *ever* behaved dishonorably about *anything* involving Debian.

I completely understand that, and how much, that hurts.  I would feel
the same way.  But it is not what I would call an insult.  This may be a
language issue.  To me, an insult is a statement that is made with the
purpose of hurting somebody.  His statement was an expression of his
anger.  Of course that hurts, and I'm sure he knows it does, but that is
not his reason for making the statement.  He honestly believes that you
actually were dishonest.  Of course, that makes it hurt even more.

I am much in favour of keeping our communication civilized; I voted for
the CoC for that reason and I am happy to see it resulting it sanctions
for people who are insulting others repeatedly (by my definition).

But I would be very uncomfortable with a rule that says you cannot say
things that hurt people.  In this case, if Ian really believes this to
be true, he is entitled to say it.  I would encourage the both of you to
have a discussion about this (in private), but whether you do that or
not, telling people they can't point out problematic behaviour because
the problem-causer would be hurt is a bad idea, IMO.

(This problem is more complex than that, though.  I don't think we need
to accept people to repeat these statements endlessly.)

On Mon, Nov 10, 2014 at 09:42:55AM +0100, Ansgar Burchardt wrote:
 I don't think it's a minor issue if a member

Re: done with consensus decisionmaking, war, rearguard battles [was: Re: REISSUED CfV: General Resolution: Init system coupling]

[Bas Wijnen]

On Sun, Nov 09, 2014 at 12:22:07PM -0800, Josh Triplett wrote:
 [CCed to a wider audience, but reply-to and mail-followup-to set to
 avoid a prolonged cross-list thread.]

 Sune Vuorela wrote:
  I have a hard time assuming good faith from people who are at war.
 
 Thank you for calling attention to that very disturbing IRC log.  I'd
 recommend reading the whole thing,

I did, and I fail to see what is disturbing about it.  I see a TC which
has a good discussion over an emotional subject.  And they succeed very
well in keeping it civil almost all of the time.

 17:14:02 Diziet bdale: The GR is going to be another 3 weeks.
 17:14:09 Diziet We should decide on the automatic switch before then IMO

What is disturbing about this?  We were about to enter a freeze.
Waiting 3 weeks before deciding on an issue which directly impacts the
release doesn't sound like a good idea.  How is that controversial?

 17:15:30 Diziet I don't think it's reasonable to say that we need a tested 
 alternative given how bad the situation is right now.

If you think the situation right now is not so bad, of course you
disagree with this.  But from his point of view, that this situation is
indeed very bad, there is nothing unreasonable about let's do
something, anything at all, to make sure this stops; problems we cause
can be fixed.

 17:34:12 dondelelcaro Diziet: I don't think that stating that we don't want 
 to swap on upgrades is something we can agree on
 17:34:25 dondelelcaro Diziet: at least, not while the GR is happening which 
 seems to directly address this part of the question
 
 17:34:28 Diziet dondelelcaro: That's not the question.  The question is 
 whether it's something that would pass a TC vote.
 17:34:32 Diziet I'm done with consensus decisionmaking.
 17:35:34 Diziet That's not to say I'm not open to convincing.  But 
 everything done by my opponents in this whole war has been done on a 
 majoritarian basis and I see no reason to limit myself to consensual acts.
 
 17:36:48 dondelelcaro Diziet: we can always go to majoritarian, but if we 
 can agree, so much the better.
 17:37:17 Diziet dondelelcaro: I and my allies have been being shat on by 
 the majoritarians since February.  It's too late for that.

Fair enough, this is a part where the level of civility is lower.  But
Ian doesn't make an unreasonable point.  If those who oppose him are
forcing their side with an overruling vote, why should he refrain from
doing the same?  Consensus is great, but if we can't get there, we do
want a decision.  And majority is better than nothing.

 (I'll also point out the pile of #action items Ian self-assigned,

What's wrong with that?  Would you rather see him say This needs to be
done; someone else do it please?  If the others would disagree that it
needs to be done, they would speak up.  That seems to be exactly the
reason he's publishing his intent to do this: to make sure there is
consensus that it is something that needs to be done.

 as well as the pile of times Ian has effectively self-referred items
 to the TC in the first place.)

He is a DD, you know?  Why would he not be allowed to refer items to the
TC?  He could of course ask a friend to do it for him, but that would
just be useless work.  He has every right to refer items to the TC.

 I've already felt from the more public portions of the TC discussions
 that Ian has been using the TC as a personal stick to hit people with.

I don't share that view at all.  Ian feels strongly about the issues,
and gets carried away at times.  IMO, that is a feature, not a bug, for
a TC member.

 Calling this a war,

Have you followed the discussion?  This _is_ a war.  And not just from
Ian's side: the pro-systemd amendment in the current vote seems to say
we demand that you trust everything we do, and we don't trust what you
do.  When I first read it my reaction was Woah!  That's a declaration
of war!  How anyone could think it would be a good idea to include that
in the amendment was beyond me.

But I think I understand it now.  Because it already is a war; no need
to declare it.  These people, just like Ian, feel strongly about this.
And that is in fact a positive thing, just like I think it is positive
that Ian feels so strongly about it.  It means that they aren't
cold-heartedly sabotaging the system as ordered by their corporate
overlords.  That may seem obvious, but it hasn't always been clear. ;-)

 To put it bluntly: I don't believe this is even remotely acceptable
 behavior from a member of the TC (or a member of the project in general,
 but in the latter case someone has less potential to cause damage).

Which part is the problem?  That he has a strong opinion?  That he wants
to speed this up and get to a decision, even without consensus?  That he
states facts?

The only problematic part I see is that he gets carried away at times.
That's a very minor issue, and I forgive him, as long as he isn't
insulting people.  In fact, I not only forgive him; I applaud him for
it; 

Re: First call for votes for the Lenny release GR

[Bas Wijnen]

On Fri, Dec 19, 2008 at 04:36:59PM -0800, Steve Langasek wrote:
 The other option you're proposing here, to prevent them from doing what they
 want to unless they have a 3:1 majority, reduces to coerce the majority to
 do what you say they should do, even though they don't think you're right.

This argument is just as true for any other time a 3:1 majority would be
used, such as when actually changing the document.  Is your position
that changing foundation documents should only require 1:1 as well?

IMO it is very reasonable to use the same requirements for changing a
document permanently of temporarily.  How about using a temporary
override for the rule that changing the constitution needs a 3:1
majority?  I think everybody will agree that allowing that would be
madness.  If we do indeed want to change our constitution with simple
majority, we should change it to say that (with 3:1 majority, of
course).

Note that this doesn't have much to do with the gr_lenny anymore.  I'm
only talking about cases where it's actually clear that a GR option is
violating a foundation document, but isn't changing it.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Bas Wijnen]

On Mon, Dec 15, 2008 at 04:16:43PM -0800, Russ Allbery wrote:
 But more fundamentally it doesn't matter.  Combining things that were
 proposed separately seems to be clearly overreaching the authority of the
 Secretary, as there's nothing in Standard Resolution Procedures which
 allows this to be done.

IMO A.1.1 allows this, and A.3.4 of course means that the secretary's
opinion on this is the correct one.

Option 1 is either meaningless or an override of a delegate decision,
but the ballot doesn't reflect this.
 
  It is a statement that a delegate decision is unconstitutional.
 
 No, it's not.  It says nothing at all about a delegate decision violating
 either the constitution or the DFSG.  The wording of choice one is a
 delegate decision override, not a statement about what is and is not in
 the consitution or the DFSG, except that it doesn't even mention there
 *was* a delegate decision.

I agree that the wording of several options, including 1 and 5, is very
vague.  I assumed that it was clear that ignoring a DFSG violation for a
release is in itself a violation of the DFSG.  This view is appearantly
not shared by everyone.  Without that assumption, I agree that option 1
is only an override of a delegate's decision.

(This makes some other stuff irrelevant, so I cut it out.)

About ignoring the DFSG:
  (Note that the constitution doesn't allow them to.)
 
 Please show me exactly where it says that.

Huh?  Should the foundation documents say that they can't be ignored?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Bas Wijnen]

On Tue, Dec 16, 2008 at 11:18:12AM -0800, Russ Allbery wrote:
 Bas Wijnen wij...@debian.org writes:
  On Mon, Dec 15, 2008 at 04:16:43PM -0800, Russ Allbery wrote:
 
  But more fundamentally it doesn't matter.  Combining things that were
  proposed separately seems to be clearly overreaching the authority of
  the Secretary, as there's nothing in Standard Resolution Procedures
  which allows this to be done.
 
  IMO A.1.1 allows this,
 
 Where?  That states how you make an amendment.  It doesn't say that the
 secretary can declare something that isn't an amendment to be an
 amendment so far as I can tell.

It says according to the requirements for a new resolution, which
seems to allow things proposed as a new resolution to really be
amendments.  I admit it's not really clear, and can as well mean that
an amendment is something different which only has the same
requirements.

  and A.3.4 of course means that the secretary's opinion on this is the
  correct one.
 
 Yes, agreed, but I can still disagree with that decision and say that it
 feels like overreaching to decide it that way.

Of course.

  No, it's not.  It says nothing at all about a delegate decision
  violating either the constitution or the DFSG.  The wording of choice
  one is a delegate decision override, not a statement about what is and
  is not in the consitution or the DFSG, except that it doesn't even
  mention there *was* a delegate decision.
 
  I agree that the wording of several options, including 1 and 5, is very
  vague.  I assumed that it was clear that ignoring a DFSG violation for a
  release is in itself a violation of the DFSG.  This view is appearantly
  not shared by everyone.
 
 Surely you realize that this phrasing is highly controversial and
 confrontational, given that the release team doesn't believe that they're
 ignoring the DFSG?

Are you talking about my wording, or about the wording of the options?
I'm sorry, but I don't see controversy or confrontation in any of them.
If you're talking about my text, then I apologize to anyone who is hurt
by it; that was not my intention at all.

 I don't believe they are either.

Neither do I.  The reason I asked was because you seemed to say that
they were, and that FD would allow them to continue doing that.  I now
understand that you didn't mean that.

 I really wish people would stop accusing other project members of
 ignoring the DFSG even if you disagree strongly with their
 interpretation of how the DFSG is applied.

I think you are talking about me here.  I haven't actually seen anyone
making this accusation.  The only time it was mentioned was when I asked
you if this was what you meant.  To be clear, I immediately followed it
with a statement saying that I didn't actually think so myself.

 If there were something in the constitution detailing decision-making
 process around foundation documents and their interpretation, it would
 have made this whole conflict easier to resolve.  But so far as I can
 tell, there isn't, apart from application to voting specifically.  Any
 such decisions therefore, under the constitution, are resolved the same
 way as any other delegate decision so far as I can tell.  There's no
 special magic that applies because one thinks a delegate decision violates
 a foundation document, nor any pre-emptive rejection of such a decision.
 
 As near as I can tell, the only thing that binds individual developers to
 follow the foundation documents are the promises that we all made when we
 joined the project to do so, which means that our understanding and
 interpretation of what they mean and how they should be applied is what is
 most relevant in the absence of a GR override of a decision.

I think I agree with this...  However, it means that if anyone (delegate
or other DD) is violating a foundation document, only a 1:1 majority is
needed to allow it by not deciding to forbid it.  That does seem
rather strange, since 3:1 would be required (IMO at least) to explicitly
decide that it is allowed.

 It's kind of an intriguing way of organizing it.  I'm not sure this is a
 bad thing.

I would have to think about that as well.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Bas Wijnen]

On Sun, Dec 14, 2008 at 02:17:19PM -0800, Russ Allbery wrote:
 * Why does releasing despite DFSG violations require a 3:1 majority now
   when it didn't for etch?  It's the same secretary in both cases.  What
   changed?  I didn't find any of the explanations offered for this very
   satisfying.

The option which is worded mostly identical to the one for etch is #5.
No 3:1 majority is needed for it.  Only options which allow non-free
firmware to be released need it.  Note that option #5 (crypically, I
admit) says we'll believe that the firmware is its own source.

 * Bundling the vote against the open opposition of a fairly significant
   number of people, including some of the people whose amendments were
   grouped together, is within his power but comes across poorly.  There
   wasn't much attempt to compromise or discuss this, and I came away from
   that with a bad taste in my mouth.

Having multiple votes on this doesn't seem like a good idea.  His
reasoning was simple and good (IMO): releasing Lenny has priority ATM.
Anything not related to that should be delayed.  Options for how do we
release Lenny? should be on this ballot.  All options have an answer
for that.  Permanently changing foundational documents is something
that's better done after the release (or at least after the decision
about how to release).

I didn't check if he was constitutionally given the power to decide
this.  However, I do think it is a good decision.

 * One role of the secretary is to interpret the constitution.  The
   constitution states fairly clearly the process of decision-making for
   decisions of this type, such as whether a given package violates the
   DFSG, or how to weigh the implications of the Social Contract.  Yet that
   decision-making process is not reflected in the ballot or in the
   presentation of the options.

   Option 1 is either meaningless or an override of a delegate
   decision, but the ballot doesn't reflect this.

It is a statement that a delegate decision is unconstitutional.  That is
something else than an override.  In case of an override, the delegate
had the power to do what he/she did, but it wasn't a good idea anyway.

   Option 4 looks equivalent to FD if you look at the decision-making
   process in the constitution, but the ballot doesn't reflect that.  I
   think some additional clarity around that would have been very helpful.

You're saying that FD means the release team will simply continue to
ignore the DFSG?  (Note that the constitution doesn't allow them to.)  I
don't actually think they are doing that (so continue isn't even
appropriate here), but option #4 would give them the right to ignore the
DFSG (regardless of whether they've been doing that so far).  Not a good
idea at all, IMO.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: The Unofficial (and Very Simple) Lenny GR: call for votes

[Bas Wijnen]

On Mon, Dec 15, 2008 at 09:35:44PM +0100, Adeodato Simó wrote:
 If more people do share your concerns, though, maybe abandoning the poll
 would be the right thing. If it's only you, I can't but offer all my
 explanations above, assert that they're true, and hope they can bring us
 somewhere.

I believe you have good intentions, but agree with Frans that this poll
only adds extra confusion to the issue.  For that reason, I am not
voting in it.  Also, I don't understand the point of ranking FD above
options you actually want in the official vote.

Especially if you want an option which requires a 3:1 majority, it seems
quite important to me that you vote it according to your preference.
I'm not really complaining, I'm only voting options 5 and 1 above FD, so
this boycott would help my preference.  But I think it would be a bad
idea to get things my way, if the developers don't actually want that.

So I ask everyone to just vote how they want things to go.  If you
don't, the only result is that things happen that you don't want.  If
you really do think that FD is better than any of the options, please
vote it highest.  But if you don't, boycotting the vote seems like a
very bad thing to do.

 One final thing: these two mails of you have brought a fair amount of
 stress on me, because of the way you say things. (Maybe you don't feel
 it's reasonable for me to feel stressed, but it's simply true that I
 was.)
 
 I have swallowed hard and replied calmly to them, because I believe
 developers, and particularly those holding key positions, should not
 ignore other developers, even if their concerns don't come in with a
 wrapping of sugar. (I don't want to ignore people in my Debian work, and
 if it ends up being impossible to deal with somebody, I'll clearly let
 them know.)
 
 However, the same way I've made an exercise and considered your views on
 actions of mine that I felt were right, I'm going to invite you make an
 exercise and consider what your style may bring onto other fellow
 developers (even if your points are right), because I know you've felt
 stressed with interactions with other developers yourself in the past,
 and it'd be bad to bring to others what you so much loathed.

I'm impressed by the way you handle this.  Thank you.

Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Bas Wijnen]

On Tue, Dec 16, 2008 at 12:45:30AM +0100, Andreas Barth wrote:
  You're saying that FD means the release team will simply continue to
  ignore the DFSG?
 
 Please stop your FUD. The release team doesn't ignore the DFSG.

Did you read the next sentence?  I'm confused with this mail, I don't
think I could have been more clear.  I'll quote myself:

On Tue, Dec 16, 2008 at 12:52:34AM +0100, Bas Wijnen wrote:
 I don't actually think they are doing that (so continue isn't even
 appropriate here),

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Bas Wijnen]

On Sun, Dec 14, 2008 at 01:44:49PM -0200, Margarita Manterola wrote:
 I'm confused by options 2 and 5:
...
 As far as I can see, the only difference between these two options is
 , and the firmware is distributed upstream under a license that
 complies with the DFSG.

That is correct.  This is actually a very big difference, which became
clear in the discussion.  Option 2 says we don't need to have the
source, while option 5 says we assume that the binary blob _is_ the
source, unless there is hard proof that it is not.  This isn't very
clear from the voting texts, but I agree with Manoj that it is the
difference between them.

It is also the reason that option 2 needs a 3:1 majority (it overrides
SC#1 because it says some things don't need source, which is a DFSG
violation), while option 5 does not (we're only being naive, and do not
trust our very strong feeling that those blobs aren't the source).

 Now, my confusion comes from the title of option 5: Assume blobs
 comply with GPL unless proven otherwise, which is not at all
 reflected in the text.  The text says that we will allow firmware that
 is distributed upstream under a license that *COMPLIES* with the DFSG.

Right.  I have no idea why Manoj kept the title like that.  It is
practically correct, since this is about firmware in the kernel, where
the license is GPL.  However, it's not in the text, and only the text
counts.

 Who will be in charge of stating what complies and what doesn't
 comply?

As usual, everyone judges on his/her own, and the technical committee
(or a GR) is needed to override a DD's decision.

 Where does this say that in evaluating what complies and what
 doesn't we will assume that the blobs are the preferred form of
 modifcation?

It says we will distribute things if we are legally allowed to do so,
and the license is DFSG-free.  It doesn't say we're going to check if
they actually follow their license.  If they don't, then (assuming this
is about the GPL) we aren't actually allowed to distribute it.

Which licenses comply and which don't doesn't seem to be a contested
matter, so there's no problem there. :-)

 And then, what's actually the difference between option 5 and option
 1? I really, sincerely, don't see how stating that we allow only
 firmware whose upstream license complies with the DFSG (option 2) is
 doing anything different of not allowing non-free firmware (option 1).

You mean s/2/5/, right?

You are correct, AFAICS, that these mean the same.  The context when
they were proposed was different, though: Robert assumed that there are
DFSG-violations, and that the release team is ignoring them (AFAIK there
are indeed bugs which claim DFSG-violations, with a lenny-ignore tag).
The proposal means to delay the release until those bugs are fixed.

Proposal 5 means, as I wrote above, that those bug reports are only a
guess, and that we should not block our release as long as nothing is
proven.  If I understand the release team right, this is their position
as well, which is why they claim that placing those lenny-ignore tags
was within their power (and with this argument, they are correct IMO).

I hope this explains,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Bas Wijnen]

On Sun, Dec 14, 2008 at 09:52:02PM +0100, Adeodato Simó wrote:
 Does the order after FD count? If I'd rank 1 and 5 below FD, with 1
 below 5, and later both reach quorum, would my ranking of 1 below 5 be
 taken into account in the 1-vs-5 run, just as if I had ranked them both
 above FD, or not?

Yes, the Condorcet voting system compares each pair of two options,
disregarding the choices about the other options.  The only information
used from the ballot is which one is higher, not how much higher.

If people are talking about strategic voting, it can (AFAICS) only be
about the situation where there is no clear winner (no option wins over
all other options).  When that happens, there are several ways to solve
it.  I don't really know which one we use, and I don't care either,
because it's a very rare situation.

There is one real missing piece of information on the ballot though: the
importance of a difference.  You can say I don't care if it's option A
or B and you can say I like option A very much more than option B.
But you can't say I like option A a little bit more than option B.
This should mean that in the race between A and B, A get a fraction of a
point instead of a full point.  I think it would be possible to add this
information to the ballot, but it would make voting much more
complicated, with hardly any gain.

Hope this helps,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Bas Wijnen]

On Sun, Dec 14, 2008 at 12:59:12PM -0800, Russ Allbery wrote:
 Bas Wijnen wij...@debian.org writes:
  On Sun, Dec 14, 2008 at 01:44:49PM -0200, Margarita Manterola wrote:
 
  Who will be in charge of stating what complies and what doesn't
  comply?
 
  As usual, everyone judges on his/her own, and the technical committee
  (or a GR) is needed to override a DD's decision.
 
 I don't believe the constitution gives the TC any say over licensing
 issues unless a DD delegates the decision to the TC.  Licensing is not a
 technical decision.  Instead, this would follow the delegate override
 path.

You have a point.

  Proposal 5 means, as I wrote above, that those bug reports are only a
  guess, and that we should not block our release as long as nothing is
  proven.  If I understand the release team right, this is their position
  as well, which is why they claim that placing those lenny-ignore tags
  was within their power (and with this argument, they are correct IMO).
 
 I believe the position of at least some of the release team is that the
 secretary's interpretation of the DFSG is incorrect and the requirement in
 the DFSG that source be available does not apply to firmware blobs on the
 grounds that they're not software in the way in which the DFSG intends.
 (This is, obviously, not a position that everyone agrees with.)

If that's their argument, then I disagree with them that they have the
power to decide that.  But let's not discuss that now, we're having a
vote about it because there was no consensus. :-)

 Choice 6 I believe was intended to make that interpretation of the
 existing DFSG the project's position as a position statement, but the
 secretary did not believe such a thing should be possible and instead
 turned it into an amendment to the DFSG.

I agree with the secretary that it is a change of the current DFSG.
There is no provision to override it, so allowing that once is an
amendment (replacing it with the same text, plus the exception allowing
this).

 Personally, I'm voting 6 highest anyway because I think amending the DFSG
 to make it completely unambiguous that we're not going to apply it to
 firmware is an even better choice than making a project statement about
 what it means.  It removes all doubt and quibbling forever going forward,
 which seems like a major win.

I agree that the DFSG should be unambiguous.  I disagree that we should
put non-free junk in main, though.  I like the idea of adding a new
section (beside main, contrib and non-free) of some non-free stuff which
is included in the installer a lot better.

But again, let's vote about that. :-)

 It's a shame that the vote was handled in the way that it was,

Actually, I think the secretary has done a very good job in preparing
the ballot.

 but I expect we'll be able to sort out something reasonable to put
 into the DFSG if it passes.

Manoj already made clear what the initial action would be: the DFSG
would be amended by adding the GR to it.  That seems like a good idea to
me; it doesn't require us to agree more than once. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Call for seconds: DFSG violations in Lenny (new proposal)

[Bas Wijnen]

On Tue, Nov 11, 2008 at 03:39:40PM +0100, Robert Millan wrote:
 I'm responding to this by proposing the following alternate option:
 
 | The Social Contract is our promise to the free software community.
 |
 | Neither the Release Team, nor any selected group of individuals, is
 | empowered to ammend the Social Contract, or grant exceptions to it;
 | Only the developers as a whole may do so, subject to the conditions in
 | section 4 of the Constitution.
 |
 | We acknowledge that such exceptions have been granted in the past (for
 | Sarge and for Etch), and that at the time of writing, a proposal that
 | might grant a similar exception for Lenny is scheduled to be voted on.
 |
 | We encourage any developers who -now and in the future- feel that one such
 | exception would be justified, to participate in its discussion and try to
 | reach consensus that can be endorsed by the majority of the project.
 
 Subject to the condition that, if my option gets enough sponsors, the
 Secretary would accept including it with Andreas' in a separate
 ballot.

Seconded.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Discussion period: GR: DFSG violations in Lenny

[Bas Wijnen]

On Tue, Nov 11, 2008 at 06:30:56PM +0100, Stefano Zacchiroli wrote:
 On Tue, Nov 11, 2008 at 05:26:18PM +0100, Robert Millan wrote:
  But if what you're trying to say is that it's not all your fault as
  Release Team, I acknowledge that.  Then again, it's a really poor
  excuse to justify missbehaviour because of pre-existing
  missbehaviour somewhere else.
 
 Well, it is a poor excuse *if* you consider the Release Team to have
 full responsibility of everything which is released in Debian.

Of course they don't.  But if the release-team tags a DFSG-violation
lenny-ignore, then they do have responsibility for setting that tag.
The result of that tag is that the known DFSG-violation is willfully
accepted into the release.  The argument is that the RMs shouldn't have
the power to decide that.

Nobody is claiming (AFAIK) that the RMs are responsible for things they
didn't notice.  This is about things they noticed, and actively
accepted.

 I think it is not the case, they should be held responsible only
 (again with double quotes, because AFAICT it is not the
 simplest/funniest job ever) for their decisions about what migrates
 and what doesn't.

Right.  And (the relevant category in this discussion) what is accepted
in the release even though there is an RC bug on it.

 The content which migrates is the main responsibility of the
 maintainer, then (in case of DFSG violations / illegal stuff) also of
 FTP masters.

Yes, but in both those cases problems can happen (and stay) because of
inactivity.  The problem with the final step is that it's active, so we
can't say sorry, we missed that one.

I'm not saying that maintainers are always doing the right thing, but
they can always claim that they didn't know about it (until a bug is
filed).  That makes that part of the problem a lot harder to fix.

 Can someone explain me why all these threads smell of gratuitous RM
 bashing?

I hope I didn't take part in that.  I'm very happy with the work done by
the RMs.  But that doesn't mean I want to give them the power to
overrule the SC without a GR.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Call for seconds: DFSG violations in Lenny

[Bas Wijnen]

On Mon, Nov 10, 2008 at 02:23:46PM +0100, Johannes Wiedersich wrote:
 Debian won't run on a large fraction of hardware any more.
...
 To restate the obvious: After the transition a lot of current debian
 users won't be using debian anymore.

So what's the problem?  We want to provide a 100% free software
distribution.  Appearantly we currently can't do that.  We're far on the
way, but not there yet.  We may have thought we were there, but we were
wrong.

So indeed, people currently running Debian don't run a 100% free
software system.  The simple obvious thing to do, seems to be (to me at
least) to remove non-free parts from main, and tell people the truth:
currently, we can't offer a 100% free solution, please use this stuff
from non-free, we're working on free solutions.

Instead you seem to invent a new rule, which says the number of users
of Debian must be as high as possible, and you even want to break SC#1
for this rule.

No, I don't agree.  I don't even agree that this is a good target.  We
shouldn't have many users as a goal.  It may be a means to help free
software.  But you're trying to argue that we should harm free software
for the purpose of getting more users.  Let's not do that, please.

Note that the SC is quite clear about helping users who need non-free
things.  We provide infrastructure and such, outside of Debian itself.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Call for seconds: DFSG violations in Lenny

[Bas Wijnen]

Hi,

I second the options quoted below.  That's the first one for the
pre-lenny GR, and the first one of the post-lenny GR.  (While I agree
that this is important, I don't think we should set procedures in the
SC; if this is to be written down in a foundational document, it must be
the constitution IMO.)

Thanks,
Bas

On Mon, Oct 27, 2008 at 04:23:05PM +0100, Robert Millan wrote:
 Option 1 (reaffirm the Social Contract)
 ~~~
 
1. We affirm that our Priorities are our users and the free software
   community (Social Contract #4);
 
2. Given that we have known for two previous releases that we have
   non-free bits in various parts of Debian, and a lot of progress has
   been made, and we are almost to the point where we can provide a
   free version of the Debian operating system, we will delay the
   release of Lenny until such point that the work to free the operating
   system is complete.

On Mon, Oct 27, 2008 at 04:56:12PM +0100, Robert Millan wrote:
 Option 1 (set an upper limit)
 ~
 
 The developers resolve that the following rule shall take effect inmediately
 after Lenny is released:
 
   When ever a package in Debian is found to have been violating the DFSG for
   180 days or more, and none of the solutions that have been implemented (if
   any) is considered suitable by the maintainers, the package must be moved
   from Debian (main suite) to the Non-free repository (non-free suite).
 
   The action of moving it may be performed by any of the developers (however,
   moving packages in distributions other than unstable or experimental may
   still require approval by the corresponding Release Team).  When this 
 happens,
   any known DFSG violation in the package must be resolved before the package
   can be moved back into Debian.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Proposed vote on issue of the day: trademarks and free software

[Bas Wijnen]

On Fri, Sep 19, 2008 at 11:56:23AM +0200, Wouter Verhelst wrote:
 ===Begin resolution text===
 The Debian Project has been watching the case around the Mozilla
 Project's EULA requirement for people wishing to use their trademarks
 from a distance. This is an issue that has been brewing for a few years
 now; and even though we've chosen not to use the Firefox, Thunderbird,
 Mozilla, and Seamonkey trademarks, we still feel that we ought to make
 our position on this important issue clear.
 
 The Free Software community as a whole is based around the notion that
 one should be allowed to modify software when they feel it necessary;
 and that the right to such modification and subsequent redistribution is
 a basic right to users that should not be taken away.
 
 The tendency that is apparent in the Mozilla Corporation, which is to
 use trademark law to enforce certain requirements which we would not
 usually consider to be characteristic of Free Software, is something
 that the Debian Project finds disturbing. Free Software is about
 Freedom; and whether that freedom is restricted through copyright law or
 trademarks really is of no concern.
 ===End resolution text===
 
 Basically, only the final paragraph changes.
 
 If my seconders can agree with this edited version, I'll retract my
 original version.

I second the new text as well.  I didn't find the previous text actually
relying on the EULA, so I don't retract support for that.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Proposed vote on issue of the day: trademarks and free software

[Bas Wijnen]

On Thu, Sep 18, 2008 at 12:56:28PM +0100, MJ Ray wrote:
 Wouter Verhelst [EMAIL PROTECTED] wrote: [...]
  For those of you who're not aware: the Mozilla Foundation is now forcing
  people who want to use their firefox trademark to display an EULA to
  their users on first run of the software. It does not currently require
  them to accept to it, so they can easily bypass the license by just
  ignoring it.
 
 While they may have changed their position, I don't think it changes
 the basic problem with Firefox failing to be Free Software due to
 trademarks.  The statement only mentions the EULA as an example of the
 problem, not as the basic problem.
...
 In short, I don't care whether someone breaks the DFSG with a
 copyright licence or a trademark licence or a death threat or whatever
 other tool.  It's about freedom, not a few laws.

Full AOL.  Thus I also second this statement:

  ===Begin resolution text===
  The Debian Project has been watching the case around the Mozilla
  Project's EULA requirement for people wishing to use their trademarks
  from a distance. This is an issue that has been brewing for a few years
  now; and even though we've chosen not to use the Firefox, Thunderbird,
  Mozilla, and Seamonkey trademarks, we still feel that we ought to make
  our position on this important issue clear.
 
  The Free Software community as a whole is based around the notion that
  one should be allowed to modify software when they feel it necessary;
  and that the right to such modification and subsequent redistribution is
  a basic right to users that should not be taken away.
 
  By using trademark law to enforce certain requirements that we do not
  usually consider to be characteristic of Free Software, such as a
  requirement for patch review and a requirement to include a particular
  end-user license, the Debian Project feels that the Mozilla Foundation
  has now turned the trademarked version of their Free Software into
  software that is no longer free.
  ===End resolution text===

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Debian Project Leader Elections 2008: Marc Brockschmidt

[Bas Wijnen]

Hi,

On Wed, Mar 05, 2008 at 09:22:19PM +, MJ Ray wrote:
 Marc 'HE' Brockschmidt [EMAIL PROTECTED] wrote: [...]
  I have contacted a few people about helping out with the tasks above
  (and some I plan to contact) but I can't hand out a definite list of
  people who are willing to help me at this time. [...]
 
 Campaigning on debian-vote *and* canvassing for help?  Is this really
 what aj meant by summarise their plans for their term?

No, this is just answering a question.  Do you suggest that he should
have delayed the answer until campaining would be allowed?

 If the project is minded to allow such discussion during nominations,
 we should shorten the discussion-only period, instead of claiming
 there's some convention that campaigning is limited to the campaign
 period.

I don't really remember the exact periods, and what is supposed to
happen when.  (And I don't care enough to look it up.)  What is the
reason we would want a campainless period during nominations?  I don't
really see any benefit.  Especially because, as this shows, it is hard
to not do campaining when answering questions (which may be raised by a
nomination).

 Any convention died years ago and candidates who campaign before and
 after the specified time seem no longer punished for it.

I see some benefit in not campaining during the voting period.  But I
don't see why anyone should be blocked from campaining before any
period.

 That would also reward early nominations and may help avoid candidates
 like Marc Brockschmidt putting the time into standing from fear of
 being left with only one unacceptable late nomination.

I don't see how that would result from not campaining during the
nomination period (or before it, for that matter).

On the contrary; early nominations risk being punished because they
talked about the DPL position in a way which some people might see as
campaining.  It would therefore lead to punished early nominations and
more fear of no good candidates (due to late nominations).

 Propose it and I'll second.

I'm not sure what you want to see proposed, but I think I don't want to
do it. ;-)  Anyway, why don't you make the proposal yourself?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Debian Project Leader Elections 2008: Marc Brockschmidt

[Bas Wijnen]

On Thu, Mar 06, 2008 at 12:57:23PM +, MJ Ray wrote:
 Bas Wijnen [EMAIL PROTECTED] wrote:
  On Wed, Mar 05, 2008 at 09:22:19PM +, MJ Ray wrote:
   Campaigning on debian-vote *and* canvassing for help?  Is this really
   what aj meant by summarise their plans for their term?
 
  No, this is just answering a question.  Do you suggest that he should
  have delayed the answer until campaining would be allowed?
 
 Yes.  Candidates should be organised enough to defer a task a few days.

Oh yes, it's not a matter of being unable to do this.  I just don't see
much point to it.  If it's only to follow the letter of the consitution,
then appearantly the constitution is wrong.  You seem to agree with me
on that. :-)  However, I don't agree with you that campaining at any
other time would violate the consitution.  See below.

  I don't really remember the exact periods, and what is supposed to
  happen when.  (And I don't care enough to look it up.)  What is the
  reason we would want a campainless period during nominations?  I don't
  really see any benefit.  [...]
 
 I want a limit on the election campaign time to try to limit the
 inevitable politicking from spilling over into more of the year.

I did look it up now.  In 5.2 the only thing that it says is 5.2.4: ...
candidates should use this time for campaigning and discussion. ...  It
doesn't say that campaining is forbidden at any other time.

This means that (if I understand you correctly) you are wrong that
campaining during the nomination period is currently forbidden, but you
are right that campaining during the rest of the year is allowed.  I
agree with you that we don't want this to lead to national politics type
stuff we see in many nations.  However, I think we don't need to create
our own problems: we don't have that problem (or at least I don't see
it), so there's no need to forbid it.  More rules only invite people to
start complaining, which leads to much less productivity.

That is, IMO we should solve hypothetical social problems by saying
we'll solve them reasonably when they are a real issue.  If talking
doesn't help, we can start making real rules then.  Only if the current
rules contradict with what we want, should we change them.  Not if they
aren't very specific.

 The benefit would be less time spent on the election, so available for
 other work.

I think this is not a real issue.  Do you feel we lose volunteer time
because people are campaining during the year?

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Debian Project Leader Elections 2008: Marc Brockschmidt

[Bas Wijnen]

On Thu, Mar 06, 2008 at 04:16:15PM +, MJ Ray wrote:
 there are claims like the limit is a convention and a convention *is*
 proper for this kind of thing. The fact that it is not totally
 respected is, IMO, not a problem, since it usually is.
 -- Wouter Verhelst
 http://lists.debian.org/debian-vote/2007/08/msg00123.html
 
 That's no longer true, even if it used to be.  Campaigning usually 
 happens before and after the campaign time.  I think we should either:-
 - take advantage of what really happens and shorten the election, or
 - establish the convention on campaign time limits.

I'd go for the second option, but I don't think we need any change for
that (and thus no proposal and no seconds).  A convention by definition
is already changed when we no longer follow it.

  That is, IMO we should solve hypothetical social problems by saying
  we'll solve them reasonably when they are a real issue.  [...]
 
 This isn't hypothetical.  Campaigning has started early for four of
 the last five elections IIRC.

But it's not a problem, AFAICS.

   The benefit would be less time spent on the election, so available for
   other work.
 
  I think this is not a real issue.  Do you feel we lose volunteer time
  because people are campaining during the year?
 
 Well, for example, Marc Brockschmidt has spent time writing a
 platform, canvassing and campaigning, which he suggested he would not
 have done if an acceptable candidate had already nominated.  If an
 acceptable candidate is nominated now, we've lost that time.  We could
 try to save that sort of time by rewarding early nominations with more
 campaigning opportunities, by officially killing the convention
 against campaigning during nominations.

If you think it helps, I have no problem with declaring that candidates
may now campain during the elections.  I just don't think it really
changes anything.  And I think it's a waste of time to do a vote on
something like that.

How about this: anyone who wants to continue informally forbidding
campaining during the nomination period please reply to this post and
explain why.  With no replies, let's consider the convention officially
killed. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Debian Project Leader Elections 2008: Marc Brockschmidt

[Bas Wijnen]

Hi Marc,

On Wed, Mar 05, 2008 at 11:40:11AM +0100, Marc 'HE' Brockschmidt wrote:
 I would like to point out that I had already resolved not to run for DPL
 this time due to the small amount of free time available to me in the
 next year. I will *not* make being DPL my top priority in the next year,
 real life issues (finishing my studies, most notably) are more important
 to me. Electing me as DPL will also reduce the time I can spend on
 release tasks, new maintainer stuff and package maintainance.

While I see you have good reasons not to run, you still candidate
yourself.  I'm interested to know why. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Supermajority requirement off-by-one error, and TC chairmanship

[Bas Wijnen]

On Sat, Feb 16, 2008 at 08:31:12PM -0800, Don Armstrong wrote:
 On Sat, 16 Feb 2008, Bas Wijnen wrote:
  Yes, that too. :-) But as I wrote, for the 50% situation, there is a
  reason we want that. We want to say there are more people in favour
  than against. With the supermajority, we want to say there are
  many more people in favour than against.
 
 Right. My main point is that for pathologically small values of voters
 such as this, changing the meaning of super-majority to include
 equality means that there is no effective difference between majority
 and super-majority. Perhaps this is a bug that should be solved by
 increasing the TC membership instead. [If 7 people are voting,
 suddenly all of these issues go away; 4/3, 5/2, and 6/1 become the magic
 numbers for N of 1, 2 and 3.]

I don't think we should bother people with TC work for statistical
reasons. ;-)  I mean, if the TC is too small, and it would be good for
it to be bigger, sure.  But just because we can't figure out how to
count the votes, doesn't seem like a good reason to add members. :-)

  When the actual value is arbitrary anyway, it makes sense to solve
  it.
 
 All of the values we pick are going to be arbitrary to at least some
 degree, so this isn't terribly convincing to me.

I think we should see that for extremely small samples, such as the TC,
statistics don't really work.  The whole idea of talking about a
percentage of the voters stems from the approximation that one voter is
an negligible part of the total.  With 6 people, it's 16 2/3%.  That's
obviously not negligible. ;-)

However, there's not much we can do about that.  Even with 7 people, you
still have the same problem if only 6 are voting.  But it seems
reasonable to me to require supermajorities in clear terms.  That is,
when we want to say at least 5/6, we should not say more than 2/3.

If we don't really want to say at least 5/6, because at least 2/3 is
good enough, then we can say that.  That was the original proposal.  I
don't really have an opinion on what the value should be, but I do think
we should say what we mean.

And of course, at least 5/6 isn't exactly the same as more than 2/3,
when some people don't vote.  So it is also possible that we do actually
want to keep it like this.  But I think it's good to do this conciously,
because what's being said doesn't seem to be what it really is.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Supermajority requirement off-by-one error, and TC chairmanship

[Bas Wijnen]

On Fri, Feb 15, 2008 at 02:11:12PM -0800, Don Armstrong wrote:
 With 6 people, 1/2 of the votes is 3 votes, with no error. more than
 1/2 needs 4 votes, or 4/6th. So even though the stated requirement is
 more than 1/2, the actual requirement is at least 4/6th. The
 difference is 1/6th of the votes, or 16 2/3%. In other words, due to
 the small sample, the requirement is more than 16% higher than
 intended.

Yes, that too. :-)  But as I wrote, for the 50% situation, there is a
reason we want that.  We want to say there are more people in favour
than against.  With the supermajority, we want to say there are many
more people in favour than against.  What exactly is the value of
many is arbitrary.  If it means 2/3, or 2/3-ε, is therefore not very
important.  If using 2/3 gives an error of 16%, then that is a small
problem.  When the actual value is arbitrary anyway, it makes sense to
solve it.  When we're talking about the 50%, the value is not arbitrary,
and changing it really changes the meaning.

 [Wonderous how the numbers work out exactly the same.]

Because that 1/6th is one voter, which is the same fraction as long
as you don't change the number of voters. :-)

On Sat, Feb 16, 2008 at 02:38:05AM +0100, Josselin Mouette wrote:
 On ven, 2008-02-15 at 22:49 +0100, Bas Wijnen wrote:
  On Fri, Feb 15, 2008 at 10:09:57PM +0100, Josselin Mouette wrote:
   On ven, 2008-02-15 at 15:50 +0100, Wouter Verhelst wrote:
Having said that, I agree with you that it makes sense for the
TC to not require 'X + 1', since the electorate is so small
anyway;
   
   I don’t understand why the previous argument wouldn’t apply to a small
   number of voters.
  
  Because of the error you're making.  With 6 people, 2/3 of the votes is
  4 votes, with no error.  more than 2/3 needs 5 votes, or 5/6th.  So
  even though the stated requirement is more than 2/3, the actual
  requirement is at least 5/6th.  The difference is 1/6th of the votes,
  or 16 2/3%.  In other words, due to the small sample, the requirement is
  more than 16% higher than intended.
 
 I know that, but I don’t think this is an “error”. The concept of
 supermajority is here for things that require a strong consensus;

Sure.  And it's fine to say for these decisions, we want a 5/6-ε
majority if we want.  Or any other fraction which seems appropriate.
That's the whole point: the actual value of how strong the consensus
needs to be is arbitrary.  If we say 2/3, then it makes sense to
adjust that according to the number of voters so that we're not really
saying something different.

For 50%, I agree that we don't want to make such adjustments, because
that number is not arbitrary.

 in a body like the TC, which is supposed to base its decisions on
 technical ground, I don’t think we can say there is strong consensus
 if only 3 people agree, 1 disagrees and 2 don’t care.

This is an argument for raising the arbitrary value of what is a
supermajority.  And an argument for saying don't care means no.  It's
fine to make these arguments, but IMO they're not appropriate in this
discussion.  This is about the technical point of lowering the
requirement by ε to make it closer to the possible results of the vote.

This obviously would lower the barrier, and I understand you don't want
that.  I think the most appropriate thing to do (assuming you do agree
with me on the ε part) is to add an option, which not only does this,
but also raises the majority we're requiring.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Supermajority requirement off-by-one error, and TC chairmanship

[Bas Wijnen]

On Fri, Feb 15, 2008 at 10:09:57PM +0100, Josselin Mouette wrote:
 On ven, 2008-02-15 at 15:50 +0100, Wouter Verhelst wrote:
  Having said that, I agree with you that it makes sense for the TC to not
  require 'X + 1', since the electorate is so small anyway;
 
 I don’t understand why the previous argument wouldn’t apply to a small
 number of voters.

Because of the error you're making.  With 6 people, 2/3 of the votes is
4 votes, with no error.  more than 2/3 needs 5 votes, or 5/6th.  So
even though the stated requirement is more than 2/3, the actual
requirement is at least 5/6th.  The difference is 1/6th of the votes,
or 16 2/3%.  In other words, due to the small sample, the requirement is
more than 16% higher than intended.

By making this change, the technical requirement is lowered by epsilon.
The real requirement though, is lowered by 16 2/3%.

This is a choice.  For 50%, I agree with Wouter that we really want an
actual majority.  For supermajories, though, I think this isn't so
important.  The precise value of how much super it needs to be is
pretty arbitrary anyway (unlike for 50%, where the meaning is most
people agree).  Setting this arbitrary value epsilon lower means that
the actual votes (in the case of small samples, such as the TC) are much
closer to what we are saying (2/3 instead of 5/6).

IMO this is totally acceptable for arbitrary values, such as 2/3, but
not for the meaningful value of 1/2.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: electing multiple people

[Bas Wijnen]

On Tue, Oct 09, 2007 at 02:50:42PM -0700, Russ Allbery wrote:
 Bernhard R. Link [EMAIL PROTECTED] writes:
 
  But if there is such an situation and there is heated disagreement
  outside of this body, how would having only one side of that in the body
  help? That would only make a body supposed to defuse such a situation to
  be weapon for one side and thus could even rise such a problem to much
  higher spheres.
 
 It depends.  Being able to reach consensus may make it easier for the
 soc-ctte to look at the situation and go there's strong disagreement here
 and even if we're mostly on one side, we realize that and we should decide
 that we can't really intervene.  I don't know if that's more likely or
 less likely with a group of people who work well together but may be
 mostly or entirely on one side of an issue, or with a group of people who
 are representative but don't work well together.

Both points are very valid: we need a representative committee (if it
should do mediation, at least), and we also need people who can work
well together.  Luckily, these are not exclusive properties. :-)

 Try this reduction of my worry (which may be very unlikely):  Suppose we
 have two basic factions in Debian, one that thinks the soc-ctte is a good
 idea, and one that thinks it's a horrible idea.  If you have proportional
 representation of both sides, that means you should elect a few people to
 the soc-ctte who think it's a horrible idea and should never do anything.
 If those people act to represent their constituency, they should try to
 block any action by the soc-ctte on any topic.

I do not think this must follow from the situation.  First of all,
whether or not the social committee is a good idea is not the sort of
conflict I would expect the social committee to solve (aside from the
fact that they're obviously a party in the conflict), because this is a
very technical thing.  Good candidates who work well together should set
aside their opinions on this when they are working on something for the
committee.  If they don't then we might have a case for the committee
(He doesn't do any of the work he's elected for, I hate him for that).
But for the moment I'll expect that this will not happen. :-)

 I'm not saying that the above is the specific problem that I'm worried
 about.  It's rather just a useful simple reduction of the sort of conflict
 that could happen over other things, and since it's so absolute, it's
 easier to reason about.

A better example (IMO) would be if half the developers are fed up with
the Cabal(tm), while the other half says it doesn't exist.  We can have
the situation that a supposed member of the Cabal (who of course claims
it doesn't exist) is also a member of the social committee.  Now what
happens when a conflict about Cabalism must be handled?

This may result in tensions between the supposedly-Cabal-member and the
Cabal-haters in the committee.  But they don't necessarily break down
the entire committee.  At least on technical grounds there is agreement
AFAIK (there should be no Cabal), and that may make things easier.

Anyway, I think this example is not very realistic either, but I thought
it'd be good to try to show what sort of things I think will be the
biggest problems of the committee.

 As mentioned, I'm very leery of this sort of situation for personal
 reasons and it may be that I'm just way too conservative about not
 creating these sorts of tensions among working groups.  It may just not be
 a problem.  It may be that the people who get elected via whatever means
 to the soc-ctte will all be people who can get along with others even if
 they disagree sharply and who know how to keep disagreements from
 escalating.  That would be great.

I think we should certainly try to find a voting method which makes
electing such a team more likely.  But it mustn't come at the cost of
representation.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: Social committee, legislature, sanctioning

[Bas Wijnen]

On Tue, Oct 09, 2007 at 02:54:00PM -0700, Russ Allbery wrote:
 The tech-ctte is the example that I think the soc-ctte is partly modelled
 after.  It works pretty well and handles internal disagreements, but it's
 aided in that by the fact that the questions are very technical and voting
 is used to resolve disagreements.  I'm not sure the same tools would work
 here.  Taking votes on difficult personal issues often ends up being a
 lose-lose situation, where every voting outcome escalates the situation in
 a different way and at least creates the appearance of factions.

Agreed.  IMO the social committee must not vote, in fact it mustn't ever
decide who is Right and who is Wrong.  For that, we could use some
judges.  Combining the function of mediator and judge in one committee
will very likely escalate problems instead of solve them.

What I think is the main task of the social committee is to defuse
situations when that is still possible.  So they must be there early on.
Some policing helps there (kicking people off IRC channels, temporary
list bans, that sort of thing), because either people will think about
their actions and conclude the sanction was appropriate, or they will
get angry and request mediation (hopefully).  Without the sanction, the
problems can grow while they remain unnoticed until it's too late to
solve them.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Social committee, legislature, sanctioning (was: Re: electing multiple people)

[Bas Wijnen]

On Tue, Oct 09, 2007 at 02:22:41AM -0700, Russ Allbery wrote:
 It's not about opinions.  It's about people.  The problem most often
 materializes when there are heated opinions, but the fundamental problem
 is when people can't work together with mutual respect.  If you end up
 with people who intensely dislike each other, the group will have an
 exceedingly hard time reaching consensus on anything.

It is very important that the people in the Social Committee can work
together well.  If we can use a voting system which makes sure we don't
elect people who dislike each other, we certainly should.  But that
doesn't mean they all have to be on the same side of important
arguments.  The members of the committee must respect each other, so
they can work together.  But they must also represent both sides (or
none) of any argument, so that they are acceptable as a mediator for
both conflicting parties.

 It's one of those sorts of landmine situations where it looks like it
 works fine up until the point where there's a major problem that provokes
 a lot of heated disagreement, and that's when the body designed to try to
 defuse such situations is most vulnerable to a breakdown of civility and
 willingness to work together among its members.

Of course.  It's a hard job, and it will likely be hard to keep the
committee together at times (but those times are exactly what the
committee is set up for).  I'm confident that we vote for people who we
expect to be good at that.  But that quality is orthogonal to most
conflicts, so having all people in the committee being able to work
together even in hard times doesn't mean they cannot be representative.

 One of the things that I find troubling about the idea of the social
 committee is that I think it takes the idea of a democratic body and
 some vague notions that smart people can work anything out and applies
 them to problems that are considerably thornier than the technical
 problems our existing example deals with.

I'm not sure what example you're talking about, but I think we all agree
that what we're trying to solve is an extremely hard problem.  But we're
Debian.  We try anyway.  And we try to do it the best way possible, not
just acceptable. :-)

 Constructing organizations that can effectively deal with social
 problems is way harder than constructing a technical committee and I'm
 worried that insufficient attention is being paid to some of the
 fuzzier aspects of how such a group can work together.

This is something I would leave to the voters.  If the voters are stupid
enough to elect stubborn people in a social committee, well, then they
get a non-functional committee.  I don't expect us to be so stupid. ;-)

However, I think a voting system which would give the candidates some
say in who they are willing to work with would be a very good idea.

 Legislatures in governments handle a spectacular degree of hostility
 and animosity, but they resolve all issues by voting and compromise is
 measured in terms of votes and voting alliances, definitely *not*
 consensus.

I think it would be good to have some kind of legislature as well.  But
they have a very different function from the social committee.  The
social committee should try to solve and prevent conflicts, while the
legislature should decide them.  Deciding a conflict should not be done
if it can be solved.  This means that the legislature should only come
into action when the social committee gives up on a problem.

A related subject is sanctioning.  At the moment, the only sanction we
have is expulsion, and we obviously don't want to use it too much.
There's been a ban for people on mailing lists (and IRC?), but that was
just done, without any rules on when and where that is acceptable
(AFAIK).  I think it would be a good idea to have some DPL delegates for
this purpose (sanctioning).  There should also be some general
guidelines, but mostly I would just leave it to their discretion.  They
should be allowed to ban people from communication media, for example.
When there is discussion about repeated abuse of that power, it can be
first mediated by the social committee, and if that doesn't work,
decided on by the legislature.  And of course anything can be overturned
by a GR.

So why do I write this here and not in a new thread?  Because IMO these
things are all connected.  The social committee is bound to fail in some
cases.  And without light sanctions, conflicts are more likely to get
out of hand.  Only installing a social committee isn't going to solve
the problems.  We need the whole system.

 Members of the executive, where most of the expectation of day-to-day
 action rests, pretty universally are chosen in part for their ability
 to work together rather than be representative of the whole
 population.

But the social committee is not comparable to the executive (that's the
police, right?).  It doesn't do sanctioning.  It's a part that is
missing in our laws, but is present in many