Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.project > #10008 > unrolled thread

Censorship in Debian

Started byDaniel Pocock <daniel@pocock.pro>
First post2018-12-20 22:50 +0100
Last post2018-12-29 01:30 +0100
Articles 20 on this page of 115 — 40 participants

Back to article view | Back to linux.debian.project


Contents

  Censorship in Debian Daniel Pocock <daniel@pocock.pro> - 2018-12-20 22:50 +0100
    Re: Censorship in Debian Adam Borowski <kilobyte@angband.pl> - 2018-12-20 23:20 +0100
    Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2018-12-20 23:20 +0100
      Re: Censorship in Debian Daniel Pocock <daniel@pocock.pro> - 2018-12-21 00:20 +0100
        Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2018-12-21 00:50 +0100
          Re: Censorship in Debian Daniel Pocock <daniel@pocock.pro> - 2018-12-21 01:30 +0100
          Re: Censorship in Debian "Paul R. Tagliamonte" <paultag@gmail.com> - 2018-12-21 01:50 +0100
            Re: Censorship in Debian Steve McIntyre <steve@einval.com> - 2019-01-04 14:40 +0100
              Re: Censorship in Debian Scott Kitterman <debian@kitterman.com> - 2019-01-04 15:00 +0100
                Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-04 19:20 +0100
                  Re: Censorship in Debian Roberto C. Sánchez <roberto@debian.org> - 2019-01-04 19:40 +0100
                    Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-04 19:50 +0100
                      Re: Censorship in Debian Roberto C. Sánchez <roberto@debian.org> - 2019-01-04 20:20 +0100
                        Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-04 21:10 +0100
                          Re: Censorship in Debian Wouter Verhelst <wouter@debian.org> - 2019-01-06 13:20 +0100
                      Re: Censorship in Debian Anthony Towns <aj@erisian.com.au> - 2019-01-05 05:00 +0100
                        Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-05 05:10 +0100
                        Re: Censorship in Debian Ian Jackson <ijackson@chiark.greenend.org.uk> - 2019-01-05 18:20 +0100
                          Re: Censorship in Debian Martin Steigerwald <martin@lichtvoll.de> - 2019-01-06 00:50 +0100
                            Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-06 01:30 +0100
                            Re: Censorship in Debian Ian Jackson <ijackson@chiark.greenend.org.uk> - 2019-01-07 19:10 +0100
                              Re: Censorship in Debian Martin Steigerwald <martin@lichtvoll.de> - 2019-01-07 19:20 +0100
                        Re: Censorship in Debian Josh Triplett <josh@joshtriplett.org> - 2019-01-10 00:00 +0100
                          Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-10 01:30 +0100
                            Re: Censorship in Debian Ben Hutchings <ben@decadent.org.uk> - 2019-01-10 06:10 +0100
                              Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-10 15:40 +0100
                            Re: Censorship in Debian Steve Langasek <vorlon@debian.org> - 2019-01-10 21:10 +0100
                              Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-10 22:10 +0100
                                Re: Censorship in Debian Matthew Vernon <matthew@debian.org> - 2019-01-10 23:30 +0100
                                  Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-11 12:20 +0100
                                    Re: Censorship in Debian Matthew Vernon <matthewv@chiark.greenend.org.uk> - 2019-01-11 14:30 +0100
                                      Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-11 20:10 +0100
                                        Re: Censorship in Debian Sam Hartman <hartmans@debian.org> - 2019-01-12 00:40 +0100
                                    Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-11 18:10 +0100
                          Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-10 01:50 +0100
                  Re: Censorship in Debian Scott Kitterman <debian@kitterman.com> - 2019-01-04 19:40 +0100
                    Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-04 20:00 +0100
                      Re: Censorship in Debian Scott Kitterman <debian@kitterman.com> - 2019-01-04 20:20 +0100
                        Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-04 20:50 +0100
                          Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-04 21:50 +0100
                            Re: Censorship in Debian Steve Langasek <vorlon@debian.org> - 2019-01-06 07:40 +0100
                              Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-06 23:00 +0100
                                Re: Censorship in Debian Ian Jackson <ijackson@chiark.greenend.org.uk> - 2019-01-07 17:00 +0100
                                  Re: Censorship in Debian Martin Steigerwald <martin@lichtvoll.de> - 2019-01-07 17:40 +0100
                                  Re: Censorship in Debian <flackjacket5@tutanota.com> - 2019-01-07 19:20 +0100
                                  Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-07 19:50 +0100
                                    Re: Censorship in Debian Steve Langasek <vorlon@debian.org> - 2019-01-08 02:00 +0100
                                      Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-08 02:20 +0100
                                        Re: Censorship in Debian Eldon Koyle <ekoyle@gmail.com> - 2019-01-08 02:50 +0100
                                          Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-08 04:00 +0100
                                            Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-08 04:10 +0100
                                              Re: Censorship in Debian Scott Kitterman <debian@kitterman.com> - 2019-01-08 04:50 +0100
                                                Re: Censorship in Debian Sam Hartman <hartmans@debian.org> - 2019-01-08 16:40 +0100
                                              Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-08 05:00 +0100
                                                Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-08 05:20 +0100
                                                  Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-08 10:40 +0100
                                        Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-08 03:20 +0100
                                          Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-08 04:40 +0100
                                            Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-08 05:00 +0100
                                              Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-08 10:20 +0100
                                                Re: Censorship in Debian Jonathan Dowland <jmtd@debian.org> - 2019-01-08 11:00 +0100
                                                  Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-08 11:30 +0100
                                                    Re: Censorship in Debian Christian Kastner <ckk@kvr.at> - 2019-01-08 12:20 +0100
                                                    Re: Censorship in Debian Ian Jackson <ijackson@chiark.greenend.org.uk> - 2019-01-08 14:30 +0100
                                                      Re: Censorship in Debian Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-08 18:20 +0100
                                                        [OT] distributions without systemd (was: Re: Censorship in Debian) Martin Steigerwald <martin@lichtvoll.de> - 2019-01-08 20:00 +0100
                                                          Re: [OT] distributions without systemd Miles Fidelman <mfidelman@meetinghouse.net> - 2019-01-08 21:50 +0100
                                                        Re: Censorship in Debian Ian Jackson <ijackson@chiark.greenend.org.uk> - 2019-01-08 20:30 +0100
                                                Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-08 20:10 +0100
                                        Re: Censorship in Debian Tollef Fog Heen <tfheen@err.no> - 2019-01-08 19:20 +0100
                          Re: Censorship in Debian Sean Whitton <spwhitton@spwhitton.name> - 2019-01-05 21:50 +0100
                            Re: Censorship in Debian Scott Kitterman <debian@kitterman.com> - 2019-01-05 22:30 +0100
                              Re: Censorship in Debian Steve Langasek <vorlon@debian.org> - 2019-01-05 23:10 +0100
                              Re: Censorship in Debian Jonathan Carter <jcc@debian.org> - 2019-01-05 23:40 +0100
                              Re: Censorship in Debian Wouter Verhelst <wouter@debian.org> - 2019-01-06 13:30 +0100
                                Re: Censorship in Debian Scott Kitterman <debian@kitterman.com> - 2019-01-06 20:10 +0100
                              Re: Censorship in Debian Sean Whitton <spwhitton@spwhitton.name> - 2019-01-06 17:20 +0100
                              Re: Censorship in Debian Martín Ferrari <tincho@tincho.org> - 2019-01-08 13:10 +0100
                Re: Censorship in Debian Jonathan Carter <jcc@debian.org> - 2019-01-04 21:40 +0100
                  Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-04 22:10 +0100
              Re: Censorship in Debian Philip Hands <phil@hands.com> - 2019-01-04 23:50 +0100
                Re: Censorship in Debian Eldon Koyle <ekoyle@gmail.com> - 2019-01-05 02:00 +0100
                  Re: Censorship in Debian Russ Allbery <rra@debian.org> - 2019-01-05 02:30 +0100
          Re: Censorship in Debian Eldon Koyle <ekoyle@gmail.com> - 2018-12-21 08:10 +0100
          Re: Censorship in Debian Martin Steigerwald <martin@lichtvoll.de> - 2018-12-21 11:30 +0100
        Re: Censorship in Debian Steve McIntyre <steve@einval.com> - 2018-12-21 01:50 +0100
          Re: Censorship in Debian Daniel Pocock <daniel@pocock.pro> - 2018-12-21 09:40 +0100
            Re: Censorship in Debian Chris Lamb <lamby@debian.org> - 2018-12-21 12:10 +0100
            Re: Censorship in Debian Geert Stappers <stappers@debian.org> - 2018-12-21 19:00 +0100
            Re: Censorship in Debian Josh Triplett <josh@joshtriplett.org> - 2018-12-22 19:30 +0100
        Re: Censorship in Debian Jonathan Dowland <jmtd@debian.org> - 2018-12-21 09:30 +0100
      Re: Censorship in Debian Adam Borowski <kilobyte@angband.pl> - 2018-12-21 04:50 +0100
        Re: Censorship in Debian Raphael Hertzog <hertzog@debian.org> - 2018-12-21 10:10 +0100
          Re: Censorship in Debian Bernd Zeimetz <bernd@bzed.de> - 2018-12-23 21:00 +0100
            Re: Censorship in Debian Marcin Kulisz <debian@kulisz.net> - 2018-12-24 10:20 +0100
              Re: Censorship in Debian Daniel Pocock <daniel@pocock.pro> - 2018-12-24 13:00 +0100
    Re: Censorship in Debian Gunnar Wolf <gwolf@debian.org> - 2018-12-21 04:00 +0100
    Re: Censorship in Debian Norbert Preining <norbert@preining.info> - 2018-12-25 17:40 +0100
      Re: Censorship in Debian martin f krafft <madduck@debian.org> - 2018-12-26 00:00 +0100
        Re: Censorship in Debian Dominik George <natureshadow@debian.org> - 2018-12-26 00:20 +0100
        Re: Censorship in Debian Steve Langasek <vorlon@debian.org> - 2018-12-29 06:40 +0100
          Re: Censorship in Debian martin f krafft <madduck@debian.org> - 2018-12-29 09:30 +0100
      Re: Censorship in Debian Charles Plessy <plessy@debian.org> - 2018-12-26 09:40 +0100
        Re: Censorship in Debian Andrey Rahmatullin <wrar@debian.org> - 2018-12-26 09:50 +0100
        Re: Censorship in Debian Holger Levsen <holger@layer-acht.org> - 2018-12-26 14:40 +0100
        Re: Censorship in Debian Charles Plessy <plessy@debian.org> - 2018-12-28 07:50 +0100
          Re: Cyberbullying (was: Censorship) in Debian Daniel Pocock <daniel@pocock.pro> - 2018-12-29 00:30 +0100
      Re: Censorship in Debian Enrico Zini <enrico@enricozini.org> - 2018-12-26 15:50 +0100
        Re: Censorship in Debian Norbert Preining <norbert@preining.info> - 2018-12-26 16:00 +0100
          Re: Censorship in Debian "Paul R. Tagliamonte" <paultag@gmail.com> - 2018-12-26 17:00 +0100
            Re: Censorship in Debian Norbert Preining <norbert@preining.info> - 2018-12-27 03:40 +0100
              Re: Censorship in Debian "Paul R. Tagliamonte" <paultag@gmail.com> - 2018-12-27 17:00 +0100
            Re: Censorship in Debian Gunnar Wolf <gwolf@debian.org> - 2018-12-27 14:50 +0100
              Re: Censorship in Debian Wouter Verhelst <wouter@debian.org> - 2018-12-28 08:50 +0100
              Re: Censorship in Debian martin f krafft <madduck@debian.org> - 2018-12-29 01:30 +0100

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →


#10169

FromSteve Langasek <vorlon@debian.org>
Date2019-01-06 07:40 +0100
Message-ID<xdagh-7rI-3@gated-at.bofh.it>
In reply to#10138

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jan 04, 2019 at 03:43:33PM -0500, Miles Fidelman wrote:
> It sure seems that, in some sectors, disagreement is offensive, and offense
> trumps substance.  (One might point to our current President in that regard,
> as well.)

> I kind of wonder if Debian is headed that way - given the way the discussion
> on systemd went, not that long ago.

I don't know where you've gotten the impression that the systemd discussion
implies Debian does not tolerate disagreement.

*Respectful* disagreement has always been tolerated regarding Debian's
choice of default init system.  What should not be tolerated (and all of
these have actually occurred on Debian mailing lists, which is why this is a
sore subject) is:

 - accusations that members of the TC have sold out to a particular
   commercial entity
 - refusal to accept the decision that was made in accordance with the
   Debian constitution
 - attempts to readjudicate the decision on Debian mailing lists (as opposed
   to via a GR, which Debian developers do have a right to use to override a
   TC decision if they believe it was wrong).
 - using a disagreement about init systems to justify attacks on developers'
   character, integrity, or technical competence

There is no expectation that everyone agree with every technical decision in
Debian.  The only expectation is that they engage constructively in spite of
any disagreements.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[toc] | [prev] | [next] | [standalone]


#10174

FromMiles Fidelman <mfidelman@meetinghouse.net>
Date2019-01-06 23:00 +0100
Message-ID<xdoCC-7HQ-15@gated-at.bofh.it>
In reply to#10169
On 1/6/19 1:38 AM, Steve Langasek wrote:

> On Fri, Jan 04, 2019 at 03:43:33PM -0500, Miles Fidelman wrote:
>> It sure seems that, in some sectors, disagreement is offensive, and offense
>> trumps substance.  (One might point to our current President in that regard,
>> as well.)
>> I kind of wonder if Debian is headed that way - given the way the discussion
>> on systemd went, not that long ago.
> I don't know where you've gotten the impression that the systemd discussion
> implies Debian does not tolerate disagreement.
>
> *Respectful* disagreement has always been tolerated regarding Debian's
> choice of default init system.  What should not be tolerated (and all of
> these have actually occurred on Debian mailing lists, which is why this is a
> sore subject) is:
>
>   - accusations that members of the TC have sold out to a particular
>     commercial entity
>   - refusal to accept the decision that was made in accordance with the
>     Debian constitution
>   - attempts to readjudicate the decision on Debian mailing lists (as opposed
>     to via a GR, which Debian developers do have a right to use to override a
>     TC decision if they believe it was wrong).
>   - using a disagreement about init systems to justify attacks on developers'
>     character, integrity, or technical competence
>
> There is no expectation that everyone agree with every technical decision in
> Debian.  The only expectation is that they engage constructively in spite of
> any disagreements.


I simply point to the number of people - including long time developers 
- who left the community over the issue.  Not to mention a completely 
wrong-headed (IMHO) process & result – and the time it took to fix the 
long-standing bugs in the installer that stood in the way of building 
without systemd (which struck me as awfully passive-aggressive).

It was far from a constructive process.

Miles Fidelman



-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]


#10178

FromIan Jackson <ijackson@chiark.greenend.org.uk>
Date2019-01-07 17:00 +0100
Message-ID<xdFtM-1eH-21@gated-at.bofh.it>
In reply to#10174
Miles Fidelman writes ("Re: Censorship in Debian"):
> On 1/6/19 1:38 AM, Steve Langasek wrote:
> > [systemd stuff]
> [systemd stuff]

I appreciate that the fights over systemd have been a defining
experience for many of us.  Many of us are still bitter, me included.
I also appreciate that in some respects these fights are still,
unfortunately, being fought and harm is still being done (although
things are much less bad than they were).

But I really don't think it is helpful to link the recent arguments
over behaviour in the project, with init system diversity problems.

The issues are very different.  And the toxic emotional and political
baggage from the init system stuff is really bad.  So bringing init
system stuff into this conversation about acceptable conduct just
increases the hurt and argument, but does not lead to any better
conclusions.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   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.

[toc] | [prev] | [next] | [standalone]


#10179

FromMartin Steigerwald <martin@lichtvoll.de>
Date2019-01-07 17:40 +0100
Message-ID<xdG6u-1HA-17@gated-at.bofh.it>
In reply to#10178
Hello,

Ian Jackson - 07.01.19, 16:57:
> Miles Fidelman writes ("Re: Censorship in Debian"):
> > On 1/6/19 1:38 AM, Steve Langasek wrote:
> > > [systemd stuff]
> > 
> > [systemd stuff]
> 
> I appreciate that the fights over systemd have been a defining
> experience for many of us.  Many of us are still bitter, me included.
> I also appreciate that in some respects these fights are still,
> unfortunately, being fought and harm is still being done (although
> things are much less bad than they were).
> 
> But I really don't think it is helpful to link the recent arguments
> over behaviour in the project, with init system diversity problems.
> 
> The issues are very different.  And the toxic emotional and political
> baggage from the init system stuff is really bad.  So bringing init
> system stuff into this conversation about acceptable conduct just
> increases the hurt and argument, but does not lead to any better
> conclusions.

As much IMO its important to let go, forgive and clean up anything still 
left over from that debate… I agree with you.

I got the impression that from reading in various threads that the 
current issues seem to be used as a dumping ground for other stuff that 
is not directly related to it.

I wonder whether it would be a good idea to have something about non-
violent, i.e. peaceful communication in one of the next major community 
events like Debconf and maybe also one about mediation.

I have read the the KDE project had something about non-violent 
communication in their last KDE Academy event.

It appears challenging to me to sort out the issues about the recent 
Code of Conduct enforcement actions without communicating face to face 
or at least via voice.

Thanks,
-- 
Martin

[toc] | [prev] | [next] | [standalone]


#10182

From<flackjacket5@tutanota.com>
Date2019-01-07 19:20 +0100
Message-ID<xdHFg-2L6-13@gated-at.bofh.it>
In reply to#10178

[Multipart message — attachments visible in raw view] — view raw


Jan 7, 2019, 3:57 PM by ijackson@chiark.greenend.org.uk:

>
> The issues are very different.  And the toxic emotional and political
> baggage from the init system stuff is really bad.  So bringing init
> system stuff into this conversation about acceptable conduct just
> increases the hurt and argument, but does not lead to any better
> conclusions.
>
>

Looks like DAM and DPL brought the toxic baggage when they decide to impose demotions on volunteers

DAM change Debian from being a community to THe Apprentice.  Sad.





--
Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
https://tutanota.com <https://tutanota.com>


[toc] | [prev] | [next] | [standalone]


#10183

FromMiles Fidelman <mfidelman@meetinghouse.net>
Date2019-01-07 19:50 +0100
Message-ID<xdI8i-2Vv-9@gated-at.bofh.it>
In reply to#10178
Ian,

On 1/7/19 10:57 AM, Ian Jackson wrote:

> Miles Fidelman writes ("Re: Censorship in Debian"):
>> On 1/6/19 1:38 AM, Steve Langasek wrote:
>>> [systemd stuff]
>> [systemd stuff]
> I appreciate that the fights over systemd have been a defining
> experience for many of us.  Many of us are still bitter, me included.
> I also appreciate that in some respects these fights are still,
> unfortunately, being fought and harm is still being done (although
> things are much less bad than they were).
>
> But I really don't think it is helpful to link the recent arguments
> over behaviour in the project, with init system diversity problems.
>
> The issues are very different.  And the toxic emotional and political
> baggage from the init system stuff is really bad.  So bringing init
> system stuff into this conversation about acceptable conduct just
> increases the hurt and argument, but does not lead to any better
> conclusions.
>
With all due respect - and recognizing your central involvement in the 
init-system-neutrality issue – I have to disagree with you here.

IMHO, the issues are VERY similar - having to do with groupthink, 
diversion from groupthink, and really, really poor processes (and 
perhaps attitudes).

It's not unlike a current issue in the church I belong to.  On the one 
hand, it's an issue over a change to one of the church's external signs 
- but it has blown up into an issue over who gets to make decisions 
(volunteer committee vs. a community-wide vote), hurt feelings among 
volunteers when someone deigns to protest a unilateral action (which 
seem to trump dissent), a rather authoritarian board that is currently 
asserting far more power than granted by our bylaws (IMHO), a seeming 
general acceptance of these authoritarian tendencies ("we don't care 
about that particular issue, so we're staying out of it"), and a general 
unwillingness to discuss issues via email list (leaving no other venue, 
other than stage managed meetings, called by our board, at their 
leisure, and at inconvenient times).  People have left over this kind of 
bull, and I'm thinking seriously about it myself (after 30 or so years).

Where Debian is concerned, the same set of issues are playing out - this 
time over the Code of Conduct, but they also played, with (IMHO) far 
more serious consequences over the systemd issues - including your own 
resignation as chair of the Technical Committee.  As you put it then, 
"While it is important that the views of the 30-40% of the project who 
agree with me should continue to be represented on the TC, I myself am 
clearly too controversial a figure at this point to do so. I should step 
aside to try to reduce the extent to which conversations about the 
project's governance are personalized."  HOW IS THIS NOT THE SAME 
SCENARIO PLAYING OUT AGAIN?"

The current discussion makes it clear that we obviously didn't learn 
anything from the systemd issue – to the severe detriment of the project 
as a whole. It strikes me as particularly relevant to point this out – 
as evidence of significant underlying pathologies that go well beyond 
the narrow issue of "acceptable conduct."  As you put it "the toxic 
emotional and political baggage from the init system stuff is really 
bad" - IMHO, the root causes are the same, and we're going through it again.

Respectfully,

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]


#10189

FromSteve Langasek <vorlon@debian.org>
Date2019-01-08 02:00 +0100
Message-ID<xdNUl-6th-3@gated-at.bofh.it>
In reply to#10183

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 07, 2019 at 01:47:41PM -0500, Miles Fidelman wrote:
> On 1/7/19 10:57 AM, Ian Jackson wrote:

> > Miles Fidelman writes ("Re: Censorship in Debian"):
> > > On 1/6/19 1:38 AM, Steve Langasek wrote:
> > > > [systemd stuff]
> > > [systemd stuff]
> > I appreciate that the fights over systemd have been a defining
> > experience for many of us.  Many of us are still bitter, me included.
> > I also appreciate that in some respects these fights are still,
> > unfortunately, being fought and harm is still being done (although
> > things are much less bad than they were).

> > But I really don't think it is helpful to link the recent arguments
> > over behaviour in the project, with init system diversity problems.

> > The issues are very different.  And the toxic emotional and political
> > baggage from the init system stuff is really bad.  So bringing init
> > system stuff into this conversation about acceptable conduct just
> > increases the hurt and argument, but does not lead to any better
> > conclusions.

> With all due respect - and recognizing your central involvement in the
> init-system-neutrality issue – I have to disagree with you here.

> IMHO, the issues are VERY similar - having to do with groupthink, diversion
> from groupthink, and really, really poor processes (and perhaps attitudes).

The process that was followed was:

 - the Technical Committee was called on to make a decision about the
   default init system in Debian (a technical matter).
 - the TC decided.
 - the Debian developers as a whole declined to overrule this decision via
   GR.

I have no sympathy for people who have so little actual investment in the
Debian Project that they haven't even read the constitution to understand
that they don't have a franchise in such decisions, but then come onto the
project's mailing lists after the fact to express outrage at a technical
decision that they disagree with.

(I have a great deal of sympathy for users who were frustrated with the
actual decision, and worried about the impact of such a major change on
their future use of Debian.  I just don't have any sympathy for those who
channeled that frustration into toxic posts on the mailing lists that sought
to browbeat Debian into changing course.)

I categorically reject the notion that a different process should have been
followed.  Giving a formal voice to a wider range of stakeholders in Debian
(i.e.: Debian users as opposed to Debian Developers) would not have made the
discussion less acrimonious; it would not have eliminated the feelings of
upset at the conclusion.  This was a decision about a default, which there
could only be one of.  There were always going to be winners and losers.

The Debian Technical Committee voted unanimously to move away from sysvinit
as the default.

To suggest that a different process would have resulted in a different
outcome is to demand the Debian constitution be rewritten to let someone
else get their way.

To suggest that a different process would have made the same outcome more
palatable to those on the losing side of the decision is naive.

Maybe you personally would have felt better about the outcome, if you
personally had been consulted.  But that doesn't scale, and provides no
basis for an amendment to the Debian decision-making processes.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[toc] | [prev] | [next] | [standalone]


#10190

FromMiles Fidelman <mfidelman@meetinghouse.net>
Date2019-01-08 02:20 +0100
Message-ID<xdOdH-6OP-1@gated-at.bofh.it>
In reply to#10189
On 1/7/19 7:57 PM, Steve Langasek wrote:

> On Mon, Jan 07, 2019 at 01:47:41PM -0500, Miles Fidelman wrote:
>> On 1/7/19 10:57 AM, Ian Jackson wrote:
>>> Miles Fidelman writes ("Re: Censorship in Debian"):
>>>> On 1/6/19 1:38 AM, Steve Langasek wrote:
>>>>> [systemd stuff]
>>>> [systemd stuff]
>>> I appreciate that the fights over systemd have been a defining
>>> experience for many of us.  Many of us are still bitter, me included.
>>> I also appreciate that in some respects these fights are still,
>>> unfortunately, being fought and harm is still being done (although
>>> things are much less bad than they were).
>>> But I really don't think it is helpful to link the recent arguments
>>> over behaviour in the project, with init system diversity problems.
>>> The issues are very different.  And the toxic emotional and political
>>> baggage from the init system stuff is really bad.  So bringing init
>>> system stuff into this conversation about acceptable conduct just
>>> increases the hurt and argument, but does not lead to any better
>>> conclusions.
>> With all due respect - and recognizing your central involvement in the
>> init-system-neutrality issue – I have to disagree with you here.
>> IMHO, the issues are VERY similar - having to do with groupthink, diversion
>> from groupthink, and really, really poor processes (and perhaps attitudes).
> The process that was followed was:
>
>   - the Technical Committee was called on to make a decision about the
>     default init system in Debian (a technical matter).
>   - the TC decided.
>   - the Debian developers as a whole declined to overrule this decision via
>     GR.
>
> I have no sympathy for people who have so little actual investment in the
> Debian Project that they haven't even read the constitution to understand
> that they don't have a franchise in such decisions, but then come onto the
> project's mailing lists after the fact to express outrage at a technical
> decision that they disagree with.


Well, first off, the process led to the resignation of the chair of the 
Technical Committee - out of a feeling that the process had become too 
"personalized."

Beyond that, there are a rather large number of folks, impacted by the 
decision, who did not have a seat at the table.  Those of us who rely on 
Debian in production, for example.  Upstream developers for another.  
Some of us knew about the issues & debates, without having a 
"franchise," others found out after the fact.  Seems to me that lack of 
representation is, in itself, a rather big failure of governance.

>
> (I have a great deal of sympathy for users who were frustrated with the
> actual decision, and worried about the impact of such a major change on
> their future use of Debian.  I just don't have any sympathy for those who
> channeled that frustration into toxic posts on the mailing lists that sought
> to browbeat Debian into changing course.)
>
> I categorically reject the notion that a different process should have been
> followed.  Giving a formal voice to a wider range of stakeholders in Debian
> (i.e.: Debian users as opposed to Debian Developers) would not have made the
> discussion less acrimonious; it would not have eliminated the feelings of
> upset at the conclusion.  This was a decision about a default, which there
> could only be one of.  There were always going to be winners and losers.

It might, however, have led to the Technical Committee giving more 
weight to the impacts of the decisions.

>
> The Debian Technical Committee voted unanimously to move away from sysvinit
> as the default.

And to making systemd the default, rather than init-neutral.  And Ian 
resigned over the issue.


>
> To suggest that a different process would have resulted in a different
> outcome is to demand the Debian constitution be rewritten to let someone
> else get their way.
>
> To suggest that a different process would have made the same outcome more
> palatable to those on the losing side of the decision is naive.
>
> Maybe you personally would have felt better about the outcome, if you
> personally had been consulted.  But that doesn't scale, and provides no
> basis for an amendment to the Debian decision-making processes.

Personally, as someone who's been involved in other organizations, and 
governance processes, I disagree, on all points.  I also suggest that 
your categorical rejection of the possibility that things could be done 
better, is illustrative of the toxicity of the current process.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]


#10191

FromEldon Koyle <ekoyle@gmail.com>
Date2019-01-08 02:50 +0100
Message-ID<xdOGJ-6Yq-1@gated-at.bofh.it>
In reply to#10190
On Mon, Jan 7, 2019 at 6:18 PM Miles Fidelman
<mfidelman@meetinghouse.net> wrote:
>
> On 1/7/19 7:57 PM, Steve Langasek wrote:
>
> > On Mon, Jan 07, 2019 at 01:47:41PM -0500, Miles Fidelman wrote:
> >> On 1/7/19 10:57 AM, Ian Jackson wrote:
> >>> Miles Fidelman writes ("Re: Censorship in Debian"):
> >>>> On 1/6/19 1:38 AM, Steve Langasek wrote:
> >>>>> [systemd stuff]
> >>>> [systemd stuff]
<snip>
> > The process that was followed was:
> >
> >   - the Technical Committee was called on to make a decision about the
> >     default init system in Debian (a technical matter).
> >   - the TC decided.
> >   - the Debian developers as a whole declined to overrule this decision via
> >     GR.
> >
> > I have no sympathy for people who have so little actual investment in the
> > Debian Project that they haven't even read the constitution to understand
> > that they don't have a franchise in such decisions, but then come onto the
> > project's mailing lists after the fact to express outrage at a technical
> > decision that they disagree with.
>
>
> Well, first off, the process led to the resignation of the chair of the
> Technical Committee - out of a feeling that the process had become too
> "personalized."
>
> Beyond that, there are a rather large number of folks, impacted by the
> decision, who did not have a seat at the table.  Those of us who rely on
> Debian in production, for example.  Upstream developers for another.
> Some of us knew about the issues & debates, without having a
> "franchise," others found out after the fact.  Seems to me that lack of
> representation is, in itself, a rather big failure of governance.
>

I think one of the reasons Debian is able to function as well as it has is
because they aren't required to put stuff out to a vote from the entire
planet.  Having technical people (developers) make technical decisions
seems appropriate, even if you disagree with the decision as a user.

There are just as many people who would be griping about sysvinit at this
juncture.  Yes, it was nice to know what your init system was doing, but
there are a lot of features that are not provided by sysvinit but are provided
by systemd.

<snip>
> >
> > To suggest that a different process would have resulted in a different
> > outcome is to demand the Debian constitution be rewritten to let someone
> > else get their way.
> >
> > To suggest that a different process would have made the same outcome more
> > palatable to those on the losing side of the decision is naive.
> >
> > Maybe you personally would have felt better about the outcome, if you
> > personally had been consulted.  But that doesn't scale, and provides no
> > basis for an amendment to the Debian decision-making processes.
>
> Personally, as someone who's been involved in other organizations, and
> governance processes, I disagree, on all points.  I also suggest that
> your categorical rejection of the possibility that things could be done
> better, is illustrative of the toxicity of the current process.

I think part of the toxicity is inherent in communicating via a mailing list.

It is very easy to feel attacked when someone points out a problem with
your argument (especially if you disagree with their counterpoints) -- even
more so when you have spent hours trying to make a logical argument that
hopefully won't offend anyone.

-- 
Eldon Koyle

[toc] | [prev] | [next] | [standalone]


#10193

FromMiles Fidelman <mfidelman@meetinghouse.net>
Date2019-01-08 04:00 +0100
Message-ID<xdPMt-7Fw-1@gated-at.bofh.it>
In reply to#10191

[Multipart message — attachments visible in raw view] — view raw

On 1/7/19 8:48 PM, Eldon Koyle wrote:

> On Mon, Jan 7, 2019 at 6:18 PM Miles Fidelman
> <mfidelman@meetinghouse.net> wrote:
>> On 1/7/19 7:57 PM, Steve Langasek wrote:
>>
>>> On Mon, Jan 07, 2019 at 01:47:41PM -0500, Miles Fidelman wrote:
>>>> On 1/7/19 10:57 AM, Ian Jackson wrote:
>>>>> Miles Fidelman writes ("Re: Censorship in Debian"):
>>>>>> On 1/6/19 1:38 AM, Steve Langasek wrote:
>>>>>>> [systemd stuff]
>>>>>> [systemd stuff]
> <snip>
>>> The process that was followed was:
>>>
>>>    - the Technical Committee was called on to make a decision about the
>>>      default init system in Debian (a technical matter).
>>>    - the TC decided.
>>>    - the Debian developers as a whole declined to overrule this decision via
>>>      GR.
>>>
>>> I have no sympathy for people who have so little actual investment in the
>>> Debian Project that they haven't even read the constitution to understand
>>> that they don't have a franchise in such decisions, but then come onto the
>>> project's mailing lists after the fact to express outrage at a technical
>>> decision that they disagree with.
>>
>> Well, first off, the process led to the resignation of the chair of the
>> Technical Committee - out of a feeling that the process had become too
>> "personalized."
>>
>> Beyond that, there are a rather large number of folks, impacted by the
>> decision, who did not have a seat at the table.  Those of us who rely on
>> Debian in production, for example.  Upstream developers for another.
>> Some of us knew about the issues & debates, without having a
>> "franchise," others found out after the fact.  Seems to me that lack of
>> representation is, in itself, a rather big failure of governance.
>>
> I think one of the reasons Debian is able to function as well as it has is
> because they aren't required to put stuff out to a vote from the entire
> planet.  Having technical people (developers) make technical decisions
> seems appropriate, even if you disagree with the decision as a user.

On the other hand, the IETF seems to do just fine - with a much larger 
base of participants, and a lot more room for discussion and debate on 
contentious issues.  Global infrastructure, with distributed ownership, 
lots of stakeholders, all held together by agreements, with the decision 
processes open to pretty much anybody who shows up.  The process puts 
pretty much everyone else to shame - with lots to be learned from it.


>
> There are just as many people who would be griping about sysvinit at this
> juncture.  Yes, it was nice to know what your init system was doing, but
> there are a lot of features that are not provided by sysvinit but are provided
> by systemd.


I'm hesitant to re-litigate the issue, but it's not about "know(ing) 
what your init system is doing," it's about impacts on both those of us 
who must administer systems, and on upstream developers.  To an awful 
lot of us, the added features of systemd add nothing, but the impacts 
are major, and damaging.

It continues to amaze me how much the interests of packagers dominate 
Debian, pushing aside the interests of those who actually develop code, 
and those who use it.  Yes, APT is great, and perhaps the primary 
selling point of Debian - but only up to a point.

>
> <snip>
>>> To suggest that a different process would have resulted in a different
>>> outcome is to demand the Debian constitution be rewritten to let someone
>>> else get their way.
>>>
>>> To suggest that a different process would have made the same outcome more
>>> palatable to those on the losing side of the decision is naive.
>>>
>>> Maybe you personally would have felt better about the outcome, if you
>>> personally had been consulted.  But that doesn't scale, and provides no
>>> basis for an amendment to the Debian decision-making processes.
>> Personally, as someone who's been involved in other organizations, and
>> governance processes, I disagree, on all points.  I also suggest that
>> your categorical rejection of the possibility that things could be done
>> better, is illustrative of the toxicity of the current process.
> I think part of the toxicity is inherent in communicating via a mailing list.
>
> It is very easy to feel attacked when someone points out a problem with
> your argument (especially if you disagree with their counterpoints) -- even
> more so when you have spent hours trying to make a logical argument that
> hopefully won't offend anyone.

Maybe - but we've kind of grown up in this world.  A lot of us in the 
networking world like to quote Postel's law:  "be conservative in what 
you do, be liberal in what you accept from others."  I've always found 
that it applies very well to email communication.  Unfortunately, it 
strikes me that people have become awfully touchy, and quick to take 
offense, these days.  Personally, I find it more uncivil when people 
take offense, than when people give it.

(It's worth noting that while "fighting words" are recognized, under 
some circumstances, as an exception to the 1st Amendment, it's pretty 
hard to avoid legal liability for violently responding to fighting 
words.  "Them's fighting words," and "them's fighting words, asshole," 
are legitimate responses.  Punching the asshole in the face is going to 
get you arrested.  Then again, calling a ref. a motherf*r, will get you 
thrown out of the game.)

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]


#10194

FromRuss Allbery <rra@debian.org>
Date2019-01-08 04:10 +0100
Message-ID<xdPW9-7Y4-3@gated-at.bofh.it>
In reply to#10193
Miles Fidelman <mfidelman@meetinghouse.net> writes:

> On the other hand, the IETF seems to do just fine - with a much larger
> base of participants, and a lot more room for discussion and debate on
> contentious issues.  Global infrastructure, with distributed ownership,
> lots of stakeholders, all held together by agreements, with the decision
> processes open to pretty much anybody who shows up.  The process puts
> pretty much everyone else to shame - with lots to be learned from it.

Speaking as someone who is a listed author on three published RFCs and
chaired one IETF working group, I will take Debian process over IETF
process any day, and find your description of the IETF pretty
entertaining.  :)

Also, please note that many IETF participants are paid as part of their
job to participate in the IETF.  (We keep coming back to that.)  That's
true of some Debian contributors as well, of course, but I strongly
suspect the percentage is lower.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]


#10196

FromScott Kitterman <debian@kitterman.com>
Date2019-01-08 04:50 +0100
Message-ID<xdQyR-8hJ-5@gated-at.bofh.it>
In reply to#10194
On Monday, January 07, 2019 07:06:28 PM Russ Allbery wrote:
> Miles Fidelman <mfidelman@meetinghouse.net> writes:
> > On the other hand, the IETF seems to do just fine - with a much larger
> > base of participants, and a lot more room for discussion and debate on
> > contentious issues.  Global infrastructure, with distributed ownership,
> > lots of stakeholders, all held together by agreements, with the decision
> > processes open to pretty much anybody who shows up.  The process puts
> > pretty much everyone else to shame - with lots to be learned from it.
> 
> Speaking as someone who is a listed author on three published RFCs and
> chaired one IETF working group, I will take Debian process over IETF
> process any day, and find your description of the IETF pretty
> entertaining.  :)
> 
> Also, please note that many IETF participants are paid as part of their
> job to participate in the IETF.  (We keep coming back to that.)  That's
> true of some Debian contributors as well, of course, but I strongly
> suspect the percentage is lower.

Similarly here (also three RFCs, but never chaired a working group).

The IETF rough consensus model is very useful in many circumstances.  I've 
used it successfully in multiple settings outside the IETF to great success in 
both moving technical work forward or driving decision making in a closed 
group to closure.  It's not relevant to the problem a group like the Debian 
tech ctte has, however.

Groups like the tech ctte have a different problem than an IETF working group.  
They have to make final decisions on things that affect the project as a 
whole, many of which are not amenable to consensus building (as an example, 
the init system decision was going to be sysv init or not sysv init - there 
was no middle ground).

I'll also remind you that the IETF process as a whole is not whoever shows up.  
IETF working groups and IETF last call are open processes.  IESG decision 
making is not.  You can have all the working group consensus you want, if 
there are uncleared discusses against your draft, it's not moving forward.  If 
you want a comparison, the tech ctte is a lot more like the IESG than an IETF 
working group.

Scott K

[toc] | [prev] | [next] | [standalone]


#10217

FromSam Hartman <hartmans@debian.org>
Date2019-01-08 16:40 +0100
Message-ID<xe1DY-6HI-19@gated-at.bofh.it>
In reply to#10196
>>>>> "Scott" == Scott Kitterman <debian@kitterman.com> writes:

    Scott> On Monday, January 07, 2019 07:06:28 PM Russ Allbery wrote:
    >> Miles Fidelman <mfidelman@meetinghouse.net> writes: > On the
    >> other hand, the IETF seems to do just fine - with a much larger >
    >> base of participants, and a lot more room for discussion and
    >> debate on > contentious issues.  Global infrastructure, with
    >> distributed ownership, > lots of stakeholders, all held together
    >> by agreements, with the decision > processes open to pretty much
    >> anybody who shows up.  The process puts > pretty much everyone
    >> else to shame - with lots to be learned from it.
    >> 
    >> Speaking as someone who is a listed author on three published
    >> RFCs and chaired one IETF working group, I will take Debian
    >> process over IETF process any day, and find your description of
    >> the IETF pretty entertaining.  :)
    >> 
    >> Also, please note that many IETF participants are paid as part of
    >> their job to participate in the IETF.  (We keep coming back to
    >> that.)  That's true of some Debian contributors as well, of
    >> course, but I strongly suspect the percentage is lower.

    Scott> Similarly here (also three RFCs, but never chaired a working
    Scott> group).

    Scott> The IETF rough consensus model is very useful in many
    Scott> circumstances.  I've used it successfully in multiple
    Scott> settings outside the IETF to great success in both moving
    Scott> technical work forward or driving decision making in a closed
    Scott> group to closure.  It's not relevant to the problem a group
    Scott> like the Debian tech ctte has, however.

    Scott> Groups like the tech ctte have a different problem than an
    Scott> IETF working group.  They have to make final decisions on
    Scott> things that affect the project as a whole, many of which are
    Scott> 
    Scott> I'll also remind you that the IETF process as a whole is not
    Scott> whoever shows up.  IETF working groups and IETF last call are
    Scott> open processes.  IESG decision making is not.  You can have
    Scott> all the working group consensus you want, if there are
    Scott> uncleared discusses against your draft, it's not moving
    Scott> forward.  If you want a comparison, the tech ctte is a lot
    Scott> more like the IESG than an IETF working group.

I've served on the Debian TC, I've served as an IETF working group
chair, and I've served on the IESG.  I think I have a fairly good handle
on the differences between the IETF and Debian processes.

The IETF process is good for developing a consensus where you want to
focus on technical quality and where you have the right stakeholders as
motivated participants.
It requires a certain familiarity with consensus building to avoid a
number of pitfalls.
IT IS NOT TIME BOUNDED.  It's great for situations where you are more
concerned with the right decision than concerned with a decision within
a particular time line.
There are ways that you can try to control the time the IETF process
takes, and it's even possible to do that if you can get a consensus on
what the timeline is and on the technical tradeoffs that are in scope
to achieve that timeline.

Debian did not meet those conditions for the init system decision by the
time it came to the TC.
Debian had already done a lot of consensus building.  We understood the
scope of the problem, we understood some of the complexities surrounding
having multiple init systems.
TC members did do some additional excellent work curating and
summarizing that knowledge (I was not on the TC at the time but was
following the discussion).

A consensus process would not have achieved the goal shared by most of
the project of having a decision in time for the jessie release.

I am unlikely to contribute to this thread again; like Ian I think
init systems are off topic.

--Sam

[toc] | [prev] | [next] | [standalone]


#10197

FromMiles Fidelman <mfidelman@meetinghouse.net>
Date2019-01-08 05:00 +0100
Message-ID<xdQIx-8lt-3@gated-at.bofh.it>
In reply to#10194
On 1/7/19 10:06 PM, Russ Allbery wrote:

> Miles Fidelman <mfidelman@meetinghouse.net> writes:
>
>> On the other hand, the IETF seems to do just fine - with a much larger
>> base of participants, and a lot more room for discussion and debate on
>> contentious issues.  Global infrastructure, with distributed ownership,
>> lots of stakeholders, all held together by agreements, with the decision
>> processes open to pretty much anybody who shows up.  The process puts
>> pretty much everyone else to shame - with lots to be learned from it.
> Speaking as someone who is a listed author on three published RFCs and
> chaired one IETF working group, I will take Debian process over IETF
> process any day, and find your description of the IETF pretty
> entertaining.  :)

Well yeah, but which "works" better in terms of results? Particularly, 
as viewed by those who are impacted by the process?

In the case of IETF, it sure seems like the needs of users, network 
operators, and equipment makers are well represented.  As compared to 
Debian, where I see little regard for either users, or upstream developers.

The WG & IETF lists tend to have less bull twaddle - though the ICANN 
transition was an interesting period, and a far more open process, if 
somewhat a foregone conclusion.

> Also, please note that many IETF participants are paid as part of their
> job to participate in the IETF.  (We keep coming back to that.)  That's
> true of some Debian contributors as well, of course, but I strongly
> suspect the percentage is lower.

Now that's definitely true.  Back in my BBN days, I was only 
peripherally involved (I tended to work on projects that contributed to 
standards work, but generally didn't go to the meetings) - I definitely 
envied some of the travel opportunities afforded to the folks who went 
to the meetings, on the company dime.  Me, I got to go to DoD meetings 
(though some of those were also in "interesting" places).

Miles



-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]


#10199

FromRuss Allbery <rra@debian.org>
Date2019-01-08 05:20 +0100
Message-ID<xdR1T-fH-1@gated-at.bofh.it>
In reply to#10197
Miles Fidelman <mfidelman@meetinghouse.net> writes:
> On 1/7/19 10:06 PM, Russ Allbery wrote:

>> Speaking as someone who is a listed author on three published RFCs and
>> chaired one IETF working group, I will take Debian process over IETF
>> process any day, and find your description of the IETF pretty
>> entertaining.  :)

> Well yeah, but which "works" better in terms of results? Particularly,
> as viewed by those who are impacted by the process?

Oh, Debian, by far.  Debian is massively more productive than the IETF per
unit of effort put in the front end.  Now, some of that is the nature of
standards development, which is inherently hard and much more contentious
than nearly all packaging problems.  But Debian puts far more work out in
the world, faster, than the IETF does relative to the resources invested.

That's part of why I'd rather work on Debian Policy than on IETF
standards.  IETF standards are very valuable, but the process redefines
the concept of slow and tedious.  And frequently, if there's no consensus,
nothing happens at all in the IETF for literally years.  (Not that this
nevery happens in Debian *cough*, but it's less common and it's usually
only relatively less important things.)

That's fine, to be clear.  I don't think that's a flaw in the IETF.  The
IETF is trying to do one thing (create general standards for the Internet)
and Debian is trying to do something far, far different and more immediate
(create and maintain a usable operating system that runs on real-world
computers).  Obviously they will be organized differently along the lines
required to achieve those goals.  But the IETF, particularly in recent
years, has increasingly become an industry consortium in which
representatives of companies negotiate with each other over how to
implement interoperable standards for their products.  Not a community of
hobbyists who are building something in large part for the joy of it.

The IETF is an excellent example of an organization where you largely have
to pay people to get them to participate in it.  There are certainly some
people who participate in IETF working groups for fun, but compared to
Debian I'm fairly sure it's limited.  People largely participate in the
IETF because they're trying to accomplish something specific *outside* the
IETF for which an IETF standard would be useful, or because they're being
paid to do so.  Not, at least to the degree that is the case in Debian,
because participating is *itself* fun and exciting and meaningful.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]


#10202

FromMiles Fidelman <mfidelman@meetinghouse.net>
Date2019-01-08 10:40 +0100
Message-ID<xdW1A-3eq-13@gated-at.bofh.it>
In reply to#10199
On 1/7/19 11:10 PM, Russ Allbery wrote:

> Miles Fidelman <mfidelman@meetinghouse.net> writes:
>> On 1/7/19 10:06 PM, Russ Allbery wrote:
>>> Speaking as someone who is a listed author on three published RFCs and
>>> chaired one IETF working group, I will take Debian process over IETF
>>> process any day, and find your description of the IETF pretty
>>> entertaining.  :)
>> Well yeah, but which "works" better in terms of results? Particularly,
>> as viewed by those who are impacted by the process?
> Oh, Debian, by far.  Debian is massively more productive than the IETF per
> unit of effort put in the front end.  Now, some of that is the nature of
> standards development, which is inherently hard and much more contentious
> than nearly all packaging problems.  But Debian puts far more work out in
> the world, faster, than the IETF does relative to the resources invested.


That really depends on what you're measuring.  Somehow, "new release of 
Debian" doesn't seem anywhere on the scale of "keeping global 
infrastructure working properly."  Of course, that involves a lot more 
than just IETF.



>
> That's part of why I'd rather work on Debian Policy than on IETF
> standards.  IETF standards are very valuable, but the process redefines
> the concept of slow and tedious.  And frequently, if there's no consensus,
> nothing happens at all in the IETF for literally years.  (Not that this
> nevery happens in Debian *cough*, but it's less common and it's usually
> only relatively less important things.)
>
> That's fine, to be clear.  I don't think that's a flaw in the IETF.  The
> IETF is trying to do one thing (create general standards for the Internet)
> and Debian is trying to do something far, far different and more immediate
> (create and maintain a usable operating system that runs on real-world
> computers).  Obviously they will be organized differently along the lines
> required to achieve those goals.  But the IETF, particularly in recent
> years, has increasingly become an industry consortium in which
> representatives of companies negotiate with each other over how to
> implement interoperable standards for their products.  Not a community of
> hobbyists who are building something in large part for the joy of it.

Well, yes, IETF is becoming more of an industry consortium - but I sure 
recognize a lot of the WG directors as names from the old days, who most 
assuredly are motivated by a lot more than a paycheck.  (Though yes, 
most folks in academia, industry, and government do like to get paid.  
And to attend meetings in interesting places on the company dime.)

>
> The IETF is an excellent example of an organization where you largely have
> to pay people to get them to participate in it.  There are certainly some
> people who participate in IETF working groups for fun, but compared to
> Debian I'm fairly sure it's limited.  People largely participate in the
> IETF because they're trying to accomplish something specific *outside* the
> IETF for which an IETF standard would be useful, or because they're being
> paid to do so.  Not, at least to the degree that is the case in Debian,
> because participating is *itself* fun and exciting and meaningful.

Pay, yes.  Create something outside of IETF - well, probably true, as 
well - but that something is "The Internet" - which is still, very much 
a work in progress.

Re. Debian - I used to think that the project founders, leaders, and 
core developers saw Debian as something more than a hobby or pet 
project.  These days, I'm not so sure.  Linux (and Linus) certainly went 
from academic project to key piece of software driving much of the 
world's computers – and the kernel development community has organized 
itself with that in mind.  Stallman, and the FSF, always, and still, see 
what they're doing as serving a broader purpose and community.  Debian 
used to present as the serious distribution for serious people (and 
perhaps, as the alternative to Red Hat) - and as a platform on which 
people could, and did depend.  These days, it sure doesn't act that way.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]


#10192

FromRuss Allbery <rra@debian.org>
Date2019-01-08 03:20 +0100
Message-ID<xdP9M-7nj-9@gated-at.bofh.it>
In reply to#10190
Miles Fidelman <mfidelman@meetinghouse.net> writes:

> Well, first off, the process led to the resignation of the chair of the
> Technical Committee - out of a feeling that the process had become too
> "personalized."

Some decisions are just hard.  I think nearly all of us involved in making
that decision burned out in various ways.  I'm not saying we couldn't have
done a better job... well, hm.  Actually, I am kind of saying that, if by
"couldn't" I include the people that we were at the time with the
emotional reserves that we had and the understanding that we had.

I could certainly do a better job *now* if I could rewind time, but that's
cheating, and humans don't get to do that.

I'm with Steve in that I'm pretty dubious that the process was the core of
why that decision was so hard.  I think it was so hard because it spanned
the gamut from technical to social issues, involved some issues that were
relatively concrete and others that were quite nebulous (such as the
interactions between the goals of the systemd developers and the broader
community), and also involved deep social divisions in the project between
folks who want Debian to be a platform for all things and folks who want
Debian to be more tightly integrated and more technically excellent along
a single axis.

This stuff is inherently very hard, particularly when friends end up on
opposite sides and believe passionately in how important their concerns
are.

I think we sometimes analyze process to death and refight the last
fourteen wars and dig up problems to argue about them some more.  We're
human, this stuff is hard, some things are going to be brutal to get
through when we disagree, and it's okay to forgive ourselves for not being
perfect.  Or even being pretty shitty at it.

That's not to say that we shouldn't look for opportunities to fix things
that we can.  For example, we certainly uncovered some nasty edge cases in
the voting mechanism for the TC, which are now fixed.  And many of us felt
that people serving for extended periods of time on the TC wasn't socially
healthy for either us or the project, so we fixed that too.

But I think there's a idealistic, utopian tendency among a lot of
technical people, myself included, to believe that any serious conflict or
(from our perspective) incorrect decision is a bug in a process somewhere,
and if we can just find the right process, we can fix the bugs.  And it's
just not true.  Humans are messy and humans disagree, and sometimes stuff
is just really hard, and is going to be really hard no matter how you do
it.

> Beyond that, there are a rather large number of folks, impacted by the
> decision, who did not have a seat at the table.  Those of us who rely on
> Debian in production, for example.  Upstream developers for another. 
> Some of us knew about the issues & debates, without having a
> "franchise," others found out after the fact.  Seems to me that lack of
> representation is, in itself, a rather big failure of governance.

Debian is *more* willing to try to take into account the needs of its
users than most free software projects, but Debian is still a volunteer
free software project, and the rule of just about every volunteer,
unfunded free software project is that the people who are doing the work
are the ones who are going to make the decisions.

Think of it this way: the people who are sufficiently invested in the
project to spend our time and energy on it over a long enough period of
time to become members are deeply invested in it and want to control where
it goes.  Plus, we're all volunteers and don't have to work on anything we
don't want to work on, which means maintaining our engagement is
absolutely necessary for the project to survive.

I understand your desire to have a say in something that's important to
you, but, well, if it's that important to you, the New Maintainer process
is right over there?  We always need more help.  Absent that, the people
who have put their blood, sweat, and tears into the project are the people
who are going to make the decisions, of course with an eye to our project
agreement to try to prioritize our users.  But it's going to be our
interpretation of what's good for our users.

If people who weren't doing the work, who weren't part of that community
and taking part of the load, were calling the shots and the rest of us had
to obey them, well... we have a word for that.  It's called a job, and the
entire relationship with the work is different, and I would expect to be
paid.

If it helps, think of having a voice in the decisions to be the pay that
we get for working on Debian.

> It might, however, have led to the Technical Committee giving more
> weight to the impacts of the decisions.

I always have to laugh at statements like that, since I think they come
from a well-meaning place of almost total lack of understanding of what it
was like to be on the TC during that decision.

I think I put more thought into all of the aspects of that decision,
including weight on the impacts of the decisions, than just about any
other decision I've made in my life.  I have put less thought into where I
live than into systemd.

I think this is part of that all-too-human belief that one's own position
is so obviously correct that if anyone disagrees with you, it's just
because they've not thought about the problem hard enough.  And it's just
not true.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]


#10195

FromMiles Fidelman <mfidelman@meetinghouse.net>
Date2019-01-08 04:40 +0100
Message-ID<xdQpb-8eh-3@gated-at.bofh.it>
In reply to#10192
On 1/7/19 9:12 PM, Russ Allbery wrote:
> Miles Fidelman <mfidelman@meetinghouse.net> writes:
>
>> Well, first off, the process led to the resignation of the chair of the
>> Technical Committee - out of a feeling that the process had become too
>> "personalized."
> Some decisions are just hard.  I think nearly all of us involved in making
> that decision burned out in various ways.  I'm not saying we couldn't have
> done a better job... well, hm.  Actually, I am kind of saying that, if by
> "couldn't" I include the people that we were at the time with the
> emotional reserves that we had and the understanding that we had.
>
> I could certainly do a better job *now* if I could rewind time, but that's
> cheating, and humans don't get to do that.

We do get to learn from things, however.

>
> I'm with Steve in that I'm pretty dubious that the process was the core of
> why that decision was so hard.  I think it was so hard because it spanned
> the gamut from technical to social issues, involved some issues that were
> relatively concrete and others that were quite nebulous (such as the
> interactions between the goals of the systemd developers and the broader
> community), and also involved deep social divisions in the project between
> folks who want Debian to be a platform for all things and folks who want
> Debian to be more tightly integrated and more technically excellent along
> a single axis.


Well, I'd argue that part of it had to do with who had a voice, and who 
didn't.  (More below.)


>
> This stuff is inherently very hard, particularly when friends end up on
> opposite sides and believe passionately in how important their concerns
> are.
>
> I think we sometimes analyze process to death and refight the last
> fourteen wars and dig up problems to argue about them some more.  We're
> human, this stuff is hard, some things are going to be brutal to get
> through when we disagree, and it's okay to forgive ourselves for not being
> perfect.  Or even being pretty shitty at it.
>
> That's not to say that we shouldn't look for opportunities to fix things
> that we can.  For example, we certainly uncovered some nasty edge cases in
> the voting mechanism for the TC, which are now fixed.  And many of us felt
> that people serving for extended periods of time on the TC wasn't socially
> healthy for either us or the project, so we fixed that too.
>
> But I think there's a idealistic, utopian tendency among a lot of
> technical people, myself included, to believe that any serious conflict or
> (from our perspective) incorrect decision is a bug in a process somewhere,
> and if we can just find the right process, we can fix the bugs.  And it's
> just not true.  Humans are messy and humans disagree, and sometimes stuff
> is just really hard, and is going to be really hard no matter how you do
> it.
>
>> Beyond that, there are a rather large number of folks, impacted by the
>> decision, who did not have a seat at the table.  Those of us who rely on
>> Debian in production, for example.  Upstream developers for another.
>> Some of us knew about the issues & debates, without having a
>> "franchise," others found out after the fact.  Seems to me that lack of
>> representation is, in itself, a rather big failure of governance.
> Debian is *more* willing to try to take into account the needs of its
> users than most free software projects, but Debian is still a volunteer
> free software project, and the rule of just about every volunteer,
> unfunded free software project is that the people who are doing the work
> are the ones who are going to make the decisions.
>
> Think of it this way: the people who are sufficiently invested in the
> project to spend our time and energy on it over a long enough period of
> time to become members are deeply invested in it and want to control where
> it goes.  Plus, we're all volunteers and don't have to work on anything we
> don't want to work on, which means maintaining our engagement is
> absolutely necessary for the project to survive.


I think you're minimizing the level of investment & commitment it takes 
to either use Debian, particularly in production, and even more, 
minimizing the efforts of upstream, and kernel, developers upon whom 
Debian ultimately depends.  There are also those who contribute by 
providing support - e.g., answering user questions on Debian lists.

As far as I can tell, the only people who count, in Debian decision 
making, are packagers - which strikes me as a rather bizarre case of the 
tail wagging the dog.  I remain amazed how much the impacts on users, 
systems administrators, and upstream developers were dismissed as 
irrelevant.

On a larger note, I point to the IETF as an example of a much larger 
community, running huge infrastructure, where pretty much anyone who 
shows up has a voice.
>
> I understand your desire to have a say in something that's important to
> you, but, well, if it's that important to you, the New Maintainer process
> is right over there?  We always need more help.  Absent that, the people
> who have put their blood, sweat, and tears into the project are the people
> who are going to make the decisions, of course with an eye to our project
> agreement to try to prioritize our users.  But it's going to be our
> interpretation of what's good for our users.

>
> If people who weren't doing the work, who weren't part of that community
> and taking part of the load, were calling the shots and the rest of us had
> to obey them, well... we have a word for that.  It's called a job, and the
> entire relationship with the work is different, and I would expect to be
> paid.
>
> If it helps, think of having a voice in the decisions to be the pay that
> we get for working on Debian.
>
>> It might, however, have led to the Technical Committee giving more
>> weight to the impacts of the decisions.
> I always have to laugh at statements like that, since I think they come
> from a well-meaning place of almost total lack of understanding of what it
> was like to be on the TC during that decision.
>
> I think I put more thought into all of the aspects of that decision,
> including weight on the impacts of the decisions, than just about any
> other decision I've made in my life.  I have put less thought into where I
> live than into systemd.
>
> I think this is part of that all-too-human belief that one's own position
> is so obviously correct that if anyone disagrees with you, it's just
> because they've not thought about the problem hard enough.  And it's just
> not true.

I'm sorry to say this, but the only value that Debian provides to the 
world, is packaging.  And, personally, over time, I've found it more and 
more necessary to download, build, and compile from source - reducing 
the value of Debian.

Pretty soon, I expect I'll be migrating.

And, next time I do any serious developing, I expect the only init 
scripts I'll provide are sysvinit based.  That suggests that my platform 
will be something other than Debian.

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]


#10198

FromRuss Allbery <rra@debian.org>
Date2019-01-08 05:00 +0100
Message-ID<xdQIx-8lt-1@gated-at.bofh.it>
In reply to#10195
Miles Fidelman <mfidelman@meetinghouse.net> writes:

> I think you're minimizing the level of investment & commitment it takes
> to either use Debian, particularly in production, and even more,
> minimizing the efforts of upstream, and kernel, developers upon whom
> Debian ultimately depends.

I really don't think I am, particularly since I've also done many of those
things, but I'm also a bit baffled as to why you think that you should get
to decide what I do with my volunteer time when you're not paying me.  I
mean, that's really what this comes down to.  Of *course* the people who
are members of the Debian project have the primary say it what it does.

> There are also those who contribute by providing support - e.g.,
> answering user questions on Debian lists.

And those people can join the project as voting members so that they can
have a say.  (I would love to see more of that, in fact; it's important to
include people in our community who do other things than package.)

> As far as I can tell, the only people who count, in Debian decision
> making, are packagers - which strikes me as a rather bizarre case of the
> tail wagging the dog.

Seriously, if you want control over something that you use, you have to
put resources into it, whether that is time or money.  You can purchase
something and have the influence of a customer and whatever contract you
can get, or you can put in sweat equity and get a voice that way.  Those
are pretty much your choices, apart from government-controlled projects.
This isn't a very radical concept.

> I remain amazed how much the impacts on users, systems administrators,
> and upstream developers were dismissed as irrelevant.

You list those things as if they're somehow distinct, when many (most,
probably) Debian Developers are all of those things.

> On a larger note, I point to the IETF as an example of a much larger
> community, running huge infrastructure, where pretty much anyone who
> shows up has a voice.

Do you know how the IETF funding model works, and how the Debian funding
model works?  You do know that the parent organization of the IETF has
paid employees, right?

The IETF is a lot more like the Linux Foundation than it is like Debian.
And that model has its place in the world, but I wouldn't be a Debian
Developer if Debian were funded and run that way.

> I'm sorry to say this, but the only value that Debian provides to the
> world, is packaging.  And, personally, over time, I've found it more and
> more necessary to download, build, and compile from source - reducing
> the value of Debian.

> Pretty soon, I expect I'll be migrating.

Okay?  I mean, you say that like you expect me to be upset, but I'm
totally okay with that, and I wish you the best of luck with whatever
operating system you migrate to.

I've said this before, but I think it's an important reality check: it
doesn't matter nearly as much who uses Debian, or how many people use
Debian, because we are not a company or a product, we don't sell
something, we're not trying to make a profit or maintain some growth
curve, and we're not part of this capitalist system.  We are building a
Linux distribution, to a very large extent, for each other, and
delightfully other people also find it useful.  Sometimes those people
even join us!  Which is great!

But we are delightfully not beholden to anyone outside the project, apart
from the much-appreciated donations of funding and equipment of course,
for our goals or even our survival.  Which means that we can have a much
more collaborative, communal decision-making process that doesn't obsess
over market share or retaining or monetizing every individual user.

> And, next time I do any serious developing, I expect the only init
> scripts I'll provide are sysvinit based.  That suggests that my platform
> will be something other than Debian.

I hope you have fun and enjoy that platform!  I'm very glad that you will
be able to find a platform that is a better fit for you.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]


#10201

FromMiles Fidelman <mfidelman@meetinghouse.net>
Date2019-01-08 10:20 +0100
Message-ID<xdVId-37Q-1@gated-at.bofh.it>
In reply to#10198

[Multipart message — attachments visible in raw view] — view raw

On 1/7/19 10:58 PM, Russ Allbery wrote:

> Miles Fidelman <mfidelman@meetinghouse.net> writes:
>
>> I think you're minimizing the level of investment & commitment it takes
>> to either use Debian, particularly in production, and even more,
>> minimizing the efforts of upstream, and kernel, developers upon whom
>> Debian ultimately depends.
> I really don't think I am, particularly since I've also done many of those
> things, but I'm also a bit baffled as to why you think that you should get
> to decide what I do with my volunteer time when you're not paying me.  I
> mean, that's really what this comes down to.  Of *course* the people who
> are members of the Debian project have the primary say it what it does.

I am not asserting any right to decide what you do with your volunteer time.

What I am asserting is that the Debian Social Contract explicitly states 
that:

"4. Our priorities are our users and free software

We will be guided by the needs of our users and the free software 
community. We will place their interests first in our priorities. We 
will support the needs of our users for operation in many different 
kinds of computing environments ... "

I DO assert that, as one user, I don't see this being honored in the 
breach, with decisions around systemd, and init-system-neutrality being 
in direct opposition to this principal.

I also suggest that users, and the "free software community" do not have 
a voice in the matter.

As to "Of *course* the people who are members of the Debian project have 
the primary say it what it does."  That does not necessarily follow.  
There are plenty of cases, in purely voluntary organizations, where 
Trustees (elected or otherwise) are expected to represent the interests 
of the broader community, and/or the broader mission of an 
organization.  An awful lot of organizations fail when current office 
holders become to insular and unresponsive.

>
>> There are also those who contribute by providing support - e.g.,
>> answering user questions on Debian lists.
> And those people can join the project as voting members so that they can
> have a say.  (I would love to see more of that, in fact; it's important to
> include people in our community who do other things than package.)
>
>> As far as I can tell, the only people who count, in Debian decision
>> making, are packagers - which strikes me as a rather bizarre case of the
>> tail wagging the dog.
> Seriously, if you want control over something that you use, you have to
> put resources into it, whether that is time or money.  You can purchase
> something and have the influence of a customer and whatever contract you
> can get, or you can put in sweat equity and get a voice that way.  Those
> are pretty much your choices, apart from government-controlled projects.
> This isn't a very radical concept.

Sure.  But in an environment as convoluted as the FOSS ecosystem, where 
and how one contributes can become pretty indirect.  For example, Debian 
depends rather heavily on the Linux kernel, the gnu tools, hosting by 
the OSU OSL - do they have a seat at the table?  What about people who 
contribute to the MoinMoin wiki, used by the Debian project?

>> I remain amazed how much the impacts on users, systems administrators,
>> and upstream developers were dismissed as irrelevant.
> You list those things as if they're somehow distinct, when many (most,
> probably) Debian Developers are all of those things.

I was watching the discussion on systemd fairly closely.  I could be 
wrong, but very little of the discussions over systemd seemed to reflect 
folks who managed production servers, or kernel developers, or 
developers of key backend software (Apache, MySQL, Postfix, Sympa, ...).

>
>> On a larger note, I point to the IETF as an example of a much larger
>> community, running huge infrastructure, where pretty much anyone who
>> shows up has a voice.
> Do you know how the IETF funding model works, and how the Debian funding
> model works?  You do know that the parent organization of the IETF has
> paid employees, right?

Yes.  Yes I do.  I also know that that ISOC was created, nominally as a 
membership organization, but no more, to create a home for the IETF 
outside of the US Government.  It's the IETF secretariat, or whatever 
it's called these days, that mostly has paid staff.  And... so?

>
> The IETF is a lot more like the Linux Foundation than it is like Debian.
> And that model has its place in the world, but I wouldn't be a Debian
> Developer if Debian were funded and run that way.
>
>> I'm sorry to say this, but the only value that Debian provides to the
>> world, is packaging.  And, personally, over time, I've found it more and
>> more necessary to download, build, and compile from source - reducing
>> the value of Debian.
>> Pretty soon, I expect I'll be migrating.
> Okay?  I mean, you say that like you expect me to be upset, but I'm
> totally okay with that, and I wish you the best of luck with whatever
> operating system you migrate to.
>
> I've said this before, but I think it's an important reality check: it
> doesn't matter nearly as much who uses Debian, or how many people use
> Debian, because we are not a company or a product, we don't sell
> something, we're not trying to make a profit or maintain some growth
> curve, and we're not part of this capitalist system.  We are building a
> Linux distribution, to a very large extent, for each other, and
> delightfully other people also find it useful.  Sometimes those people
> even join us!  Which is great!

Well, I'll go back to the Social Contract - "We will be guided by the 
needs of our users and the free software community. We will place their 
interests first in our priorities."  If you're not upset when folks 
abandon Debian, or fork it, or stop recommending it.

>
> But we are delightfully not beholden to anyone outside the project, apart
> from the much-appreciated donations of funding and equipment of course,
> for our goals or even our survival.  Which means that we can have a much
> more collaborative, communal decision-making process that doesn't obsess
> over market share or retaining or monetizing every individual user.
>
>> And, next time I do any serious developing, I expect the only init
>> scripts I'll provide are sysvinit based.  That suggests that my platform
>> will be something other than Debian.
> I hope you have fun and enjoy that platform!  I'm very glad that you will
> be able to find a platform that is a better fit for you.
>
-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

[toc] | [prev] | [next] | [standalone]


Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

Back to top | Article view | linux.debian.project


csiph-web