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

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

Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

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

Contents

  Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Sam Hartman <hartmans@debian.org> - 2017-10-28 02:30 +0200
    Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Martin Steigerwald <martin@lichtvoll.de> - 2017-10-28 13:40 +0200
      Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Russ Allbery <rra@debian.org> - 2017-10-29 01:20 +0200
        Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Martin Steigerwald <martin@lichtvoll.de> - 2017-10-31 11:10 +0100
          Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Russ Allbery <rra@debian.org> - 2017-10-31 17:20 +0100
            Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Sam Hartman <hartmans@debian.org> - 2017-10-31 17:50 +0100
              Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the  Technical Committee Luk Claes <luk.claes@gmail.com> - 2017-10-31 18:20 +0100
            Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Tollef Fog Heen <tfheen@err.no> - 2017-10-31 18:40 +0100
              Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the  Technical Committee Marty <martyb@ix.netcom.com> - 2017-11-03 23:00 +0100
                Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about  the Technical Committee Steve Langasek <vorlon@debian.org> - 2017-11-04 00:40 +0100
                  Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the  Technical Committee Marty <martyb@ix.netcom.com> - 2017-11-07 02:20 +0100
                    Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Russ Allbery <rra@debian.org> - 2017-11-07 04:00 +0100
                      Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about  the Technical Committee Norbert Preining <preining@logic.at> - 2017-12-26 15:40 +0100
                        Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Martin Steigerwald <martin@lichtvoll.de> - 2017-12-26 16:10 +0100
                          Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-28 11:30 +0100
                            Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Martin Steigerwald <martin@lichtvoll.de> - 2017-12-28 13:50 +0100
                            Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Martin Steigerwald <martin@lichtvoll.de> - 2017-12-28 13:50 +0100
                              Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the  Technical Committee Paul Wise <pabs@debian.org> - 2017-12-28 14:00 +0100
                              Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Tollef Fog Heen <tfheen@err.no> - 2017-12-28 19:40 +0100
            Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-10-31 18:40 +0100
              Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Sam Hartman <hartmans@debian.org> - 2017-11-02 14:20 +0100
                Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-11-02 14:50 +0100
                  Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about  the Technical Committee Diane Trout <diane@ghic.org> - 2017-11-02 19:50 +0100
                    Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about  the Technical Committee Steve Langasek <vorlon@debian.org> - 2017-11-04 00:50 +0100
                      Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Sam Hartman <hartmans@debian.org> - 2017-11-04 02:20 +0100
                        Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Scott Kitterman <debian@kitterman.com> - 2017-11-04 02:50 +0100
                          Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about  the Technical Committee Diane Trout <diane@ghic.org> - 2017-11-04 06:40 +0100
                          Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Didier 'OdyX' Raboud <odyx@debian.org> - 2017-11-05 17:10 +0100
                        Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about  the Technical Committee Diane Trout <diane@ghic.org> - 2017-11-04 05:20 +0100
                  Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Sam Hartman <hartmans@debian.org> - 2017-11-03 14:10 +0100
      Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about  the Technical Committee Don Armstrong <don@debian.org> - 2017-10-29 05:30 +0100
    Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about  the Technical Committee Gunnar Wolf <gwolf@debian.org> - 2017-10-29 00:00 +0200
      Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee Russ Allbery <rra@debian.org> - 2017-10-29 01:30 +0200

Page 1 of 2  [1] 2  Next page →

#9584 — Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

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

As a member of the technical committee, I've grown increasingly alarmed
as I think about the impact of the issues that come to us.
Yes, we're giving answers.  However, I think we are doing a lot of harm
to the members of our community in the process, and I would like to
explore whether we can do better.

I've written a blog entry describing my concerns.  It's on Planet, and
you can see it at https://hartmans.livejournal.com/97174.html

I've reached a point where I'd like to share my concerns and ask "anyone
else feel similar?  Anyone else want to work on solving this?"

In thinking about my concerns I went over a list of issues that have
come before the TC going back somewhat before the Systemd discussion.
However, I did not perform any quantitative or statistical analysis.
As you can see I also didn't share any discussion of specific issues.
I'm not trying to persuade you I'm right.  I am very interested in being
exposed to your ideas about how one might think about this situation,
and certainly exposing me to new ways of thinking is likely to change my
opinions.  But I'm not really interested in persuasion either incoming
or outgoing at this point.  I'm seeking shared interest.

If we get to a point where we want to propose a specific change, we'll
need to convince the project it will make things better.  That's a ways
down this road.

[toc] | [next] | [standalone]

#9586

Hello Sam.

Sam Hartman - 27.10.17, 20:18:
> As a member of the technical committee, I've grown increasingly alarmed
> as I think about the impact of the issues that come to us.
> Yes, we're giving answers.  However, I think we are doing a lot of harm
> to the members of our community in the process, and I would like to
> explore whether we can do better.
> 
> I've written a blog entry describing my concerns.  It's on Planet, and
> you can see it at https://hartmans.livejournal.com/97174.html
>
> 
> I've reached a point where I'd like to share my concerns and ask "anyone
> else feel similar?  Anyone else want to work on solving this?"

Thank you for that.

I always found that just focusing on the technical aspects of the Init system 
discussion left out… everything else. Even the issue in itself was not purely 
technical, although back then I had the a feeling that almost no one agreed 
with me that it was not. Just focusing on purely technical means in that 
discussion was in my eyes harmful in itself.

During posting in those endless mailing list threads back then and then being 
moderated by listmasters… asking myself "why me? … and not everyone else as 
well?" I felt so hurt, that I wanted to give up maintaining my few packages. 
So the discussion process itself *even* before involving the Tech-CTTE was 
harmful in my perception.

> In thinking about my concerns I went over a list of issues that have
> come before the TC going back somewhat before the Systemd discussion.
> However, I did not perform any quantitative or statistical analysis.

Do you think decisions of the Tech-CTTE or the process around it changed 
significantly during the Init system decision process? I can imagine that this 
debate back then left a lot of bitterness in quite some of the people who 
engaged with it and I would not be surprised that the decision processes after 
this debate more easily turned into fierce battles than before.

I know the one of the most important ingredients to heal wounds of the past: 
It is forgiveness. The past… is in the past. I know how challenging it can be 
to let go of it.

> If we get to a point where we want to propose a specific change, we'll
> need to convince the project it will make things better.  That's a ways
> down this road.

I have no firm idea how a change could look like, but I think I have a hunch on 
some important aspects in this:

I think it is important to understand the nature of conflicts in order to move 
beyond. Common responses to conflicts are either fight or flight, or stand still 
and hope no one will notice you. These responses can be life saving in death-
or-life conflicts, but are often not beneficial in complex decision processes 
that involve technical, social, ethical and personality aspects like within 
Debian. So an important question is: If I neither fight nor flew away or stand 
still and freeze, what will I be doing then?

I agree with you that an important aspect is that each party receives the 
chance to fully express their own position and be heard, seen, felt and 
valued. So I think there needs to be a shift to see conflicts as something 
positive and provide a safe space to express them.

Challenging for me is the answer to the question: How can such a safe place 
look like in a community that is spread around the globe and can often only 
connect via the means of the internet?

Thanks,
-- 
Martin

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

#9588

Martin Steigerwald <martin@lichtvoll.de> writes:

> I always found that just focusing on the technical aspects of the Init
> system discussion left out… everything else. Even the issue in itself
> was not purely technical, although back then I had the a feeling that
> almost no one agreed with me that it was not. Just focusing on purely
> technical means in that discussion was in my eyes harmful in itself.

Well, I agreed, and agree, with you that the issue was not purely
technical, and spent a substantial amount of time, effort, and writeup
energy on discussing the non-technical issues.  Your description bears
very little resemblence to the process I was part of.

I think it's really important to not oversimplify past discussions.  We're
in danger of learning the wrong lessons from them.

One of the reasons why the systemd discussion was so painful was precisely
that it could *not* be discussed at a level of purely technical details,
and we all knew it.  Technical details are much easier to reach decisions
of fact on; the systemd discussion was painful precisely because it
*wasn't* and *couldn't* be conducted in the way that you describe.  It
touched on everything from competing visions of the nature of free
software in the project, the meaning of our social contract and
"universal" in the motto of our distribution, the attitudes and behavior
of multiple different upstreams, accusations of corporate conflict of
interest, and deep personal friendships.

There wasn't *anything* "left out" of that discussion.

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

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

#9595

Dear Russ, dear Sam, dear people involved with Debian,

Russ Allbery - 28.10.17, 16:13:
> Martin Steigerwald <martin@lichtvoll.de> writes:
> > I always found that just focusing on the technical aspects of the Init
> > system discussion left out… everything else. Even the issue in itself
> > was not purely technical, although back then I had the a feeling that
> > almost no one agreed with me that it was not. Just focusing on purely
> > technical means in that discussion was in my eyes harmful in itself.
> 
> Well, I agreed, and agree, with you that the issue was not purely
> technical, and spent a substantial amount of time, effort, and writeup
> energy on discussing the non-technical issues.  Your description bears
> very little resemblence to the process I was part of.

As always perceptions of different people are different…

> I think it's really important to not oversimplify past discussions.  We're
> in danger of learning the wrong lessons from them.
> 
> One of the reasons why the systemd discussion was so painful was precisely
> that it could *not* be discussed at a level of purely technical details,
> and we all knew it.  […]

My impression from what I read of the discussion was exactly as I described… 
so I did not simplify it by conscious choice…

however I do not claim having read all of it. I also do not claim to remember 
all that I read. It was a *ton* of mails back then and at one point there was 
what I received as moderation but apparently was not meant as one by Don, and 
I decided I could not bear this any longer. I decided to let go of it as best 
as I can. I did not read any of the mails past that point in time.

So yes, I may have simplified it.

> There wasn't *anything* "left out" of that discussion.

In my opinion this is a pretty bold statement.

If everyone has been heard, noticed, felt and valued, if everything has been 
covered, then why are we discussing it… yet again now?

If the conflict resolution process proceeded to its completion, there is no 
reason to.

Moving in circles, as I had the impression the discussion moved in back then 
is not proceeding to its completion. Its the attribute of a circle that I can 
walk its outline forever especially when I do not notice that I am doing so.

So is it merely me wanting badly to have a problem again – or Sam wanting to? 
Or, is there still something left to be noticed, welcomed, embraced and let go 
of? Is there still something that you, understandably, deny by not wanting to 
have that problem again? Only you can answer that question by noticing what 
you feel, so I don´t even try to. Also its not only a question you can choose 
to ask, but one everyone can choose to ask, including myself.

Each one of us can do this work on his or her own. And I am certainly willing 
to.

I certainly think that the CTTE process can be improved upon. Is it bad? I do 
not know and does it really matter to decide? I am sure everyone involved is 
doing their best. We always do.

Can it be improved upon? Yes, is my answer.

I trust to find the answer as to how within me. I may share it when I find it 
at a later time, if its still important to share it then.

One part of an answer for me is within the question I asked here implicitly:

Does the everyone involved with CTTE process drive conflict resolution 
processes to their completion?

Or does someone or a group of people decide to prematurely stop it cause they, 
again, understandably, can not bear it anymore and want to get rid of it? If 
so, what change in how I see a conflict can help me to move beyond?

And can I let go whether moving beyond would be superhuman or not? What is 
human anyway? Am I my human experience?

I let go of any desire to change things now as I just catched myself of 
holding onto it. In the end I am still with the Debian project. I just did a 
new version of fio package. And I keep myself somewhat informed about what 
people do in the Devuan project as well. So what happens if I just accept 
things as they are, just for now?

Thanks,
-- 
Martin

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

#9596

Martin Steigerwald <martin@lichtvoll.de> writes:
> Russ Allbery - 28.10.17, 16:13:

>> There wasn't *anything* "left out" of that discussion.

> In my opinion this is a pretty bold statement.

> If everyone has been heard, noticed, felt and valued, if everything has
> been covered, then why are we discussing it… yet again now?

Those are not equivalent statements.  In that sort of discussion, it is
literally impossible to make everyone feel valued, since at least some
people on each side will only feel valued if their preferred option is
chosen.  That's therefore not a reasonable thing to attempt to achieve; we
can try to maximize the number of people who feel valued, but there are
usually at least some people involved in this large and sprawling of a
decision for whom "valued" is synonymous with "agreed with."

There are two primary reasons why we're continuing to discuss this.  One
is that the decision went a direction that a lot of people didn't, and
don't, like, and they're still unhappy about it.  There's really nothing
that can be done about this; any other decision would have had exactly the
same consequence, just with a different set of people.

The second is that there is a very strong tendency for humans to confuse
"you have heard and fully understand everything I said and simply don't
agree with me" with "you haven't heard me."  I think everyone does this to
some extent.  We're all firmly convinced that our arguments are the best
(since if they weren't, we'd hold a different opinion), and therefore if
someone doesn't agree with us, it must be because they just haven't
*really* heard and understood our arguments.  It's very, *very* hard to
not believe this.  And a *ton* of that happened, and continues to happen,
with systemd.

But... it's just not true.

I'm quite confident that everyone on the TC who made the systemd
discussion fully understood the arguments for the opposing side.  We
simply didn't agree.  And we have to find some way, as project members and
as human beings, to accept that and live with it.  Part of living with it
is not trying to come up with *yet another* phrasing of the argument that,
this time, the other side will *finally* understand.

This phenomenon is not at all unique to Debian.  It happens in all
political discussions.

> I certainly think that the CTTE process can be improved upon. Is it bad?
> I do not know and does it really matter to decide? I am sure everyone
> involved is doing their best. We always do.

> Can it be improved upon? Yes, is my answer.

I'm certainly happy to agree with this!  There's hardly any human process
that can't be improved upon.

My key point here is that if you think there was some other way that the
systemd discussion could have been held, some additional work that could
have been done, such that everyone would have been happy with the
outcome... well, sadly, I just don't think that was on the table.

There are certainly things we could have done better, mechanically,
culturally, interpersonally.  But there was no *argument* left out of that
discussion that would have convinced people, and there was zero chance
that we weren't going to come out of that decision with some very upset
and angry project members.

> Does the everyone involved with CTTE process drive conflict resolution
> processes to their completion?

I don't think the type of conclusion that you're talking about here (I
sense that you're talking about something other than a mechanical
conclusion of a defined process) is something that exists with truly hard
decisions.  This feels like an argument for always making decisions by
consensus, and the sad fact of the matter is that some decisions cannot be
made by consensus because there is no consensus and *will never be a
consensus*.

In those situations, in practice, this line of argument is an argument for
not making a decision, by perpetually postponing the decision because the
conflict resolution hasn't completed, because some people are still
unhappy.  And not making a decision is itself a decision, often a rather
bad one.

The other point I want to make here is that the systemd discussion was one
of the most exhausting and time-consuming things that I've ever been
involved in.  I'm sure some people in that discussion didn't feel listened
to for various reasons, and maybe in a few cases that was because they
truly weren't listened to.  (Perhaps because they were making other
versions of the same arguments other people were making.)  But at least
speaking for myself, there was not the *capacity*, emotional or temporal,
to engage in more detailed personal discussions with yet more people to
make sure they felt fully heard.  This is some of the "being human" part
that I was talking about in my other message.  Making people heard can be
incredibly time-consuming and can require a ton of emotional energy, and
TC members, like all project members, are volunteers.  Often with very
limited quantities of time they can spend on Debian.

You're asking more than I think you realize by asking people to ensure
everyone in the project feels fully listened to.

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

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

#9597

>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:

    Russ> Martin Steigerwald <martin@lichtvoll.de> writes:
    >> Russ Allbery - 28.10.17, 16:13:

    >>> There wasn't *anything* "left out" of that discussion.

    >> In my opinion this is a pretty bold statement.

    >> If everyone has been heard, noticed, felt and valued, if
    >> everything has been covered, then why are we discussing it… yet
    >> again now?

    Russ> Those are not equivalent statements.  In that sort of
    Russ> discussion, it is literally impossible to make everyone feel
    Russ> valued, since at least some people on each side will only feel
    Russ> valued if their preferred option is chosen.  That's therefore
    Russ> not a reasonable thing to attempt to achieve; we can try to
    Russ> maximize the number of people who feel valued, but there are
    Russ> usually at least some people involved in this large and
    Russ> sprawling of a decision for whom "valued" is synonymous with
    Russ> "agreed with."

For myself, I've found that if I work with people I can often get to a
point where they feel valued even when there is disagreement.
As you point out that's not true for some people and it is difficult
even when it is possible.

I was not planning on discussing systemd again.

I am discussing how we handle conflict because I hope we can do a better
job of helping  people feel valued even when we do not agree with their
technical positions.
In the limit, I hope to do your literally impossible:-)

Fortunately, I'd be thrilled and filled with joy to simply get closer to
that limit.  Helping create a culture where we have mechanisms to help
ourselves separate value from agreement, and where we value using those
mechanisms would delight me.
I think even that is a hard ask, but I do not think it is literally
impossible.

--Sam

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

#9598 — Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

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

+1

On Tue, Oct 31, 2017 at 5:46 PM, Sam Hartman <hartmans@debian.org> wrote:

> >>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
>
>     Russ> Martin Steigerwald <martin@lichtvoll.de> writes:
>     >> Russ Allbery - 28.10.17, 16:13:
>
>     >>> There wasn't *anything* "left out" of that discussion.
>
>     >> In my opinion this is a pretty bold statement.
>
>     >> If everyone has been heard, noticed, felt and valued, if
>     >> everything has been covered, then why are we discussing it… yet
>     >> again now?
>
>     Russ> Those are not equivalent statements.  In that sort of
>     Russ> discussion, it is literally impossible to make everyone feel
>     Russ> valued, since at least some people on each side will only feel
>     Russ> valued if their preferred option is chosen.  That's therefore
>     Russ> not a reasonable thing to attempt to achieve; we can try to
>     Russ> maximize the number of people who feel valued, but there are
>     Russ> usually at least some people involved in this large and
>     Russ> sprawling of a decision for whom "valued" is synonymous with
>     Russ> "agreed with."
>
> For myself, I've found that if I work with people I can often get to a
> point where they feel valued even when there is disagreement.
> As you point out that's not true for some people and it is difficult
> even when it is possible.
>
> I was not planning on discussing systemd again.
>
> I am discussing how we handle conflict because I hope we can do a better
> job of helping  people feel valued even when we do not agree with their
> technical positions.
> In the limit, I hope to do your literally impossible:-)
>
> Fortunately, I'd be thrilled and filled with joy to simply get closer to
> that limit.  Helping create a culture where we have mechanisms to help
> ourselves separate value from agreement, and where we value using those
> mechanisms would delight me.
> I think even that is a hard ask, but I do not think it is literally
> impossible.
>
> --Sam
>
>

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

#9599

]] Russ Allbery 

> There are two primary reasons why we're continuing to discuss this.  One
> is that the decision went a direction that a lot of people didn't, and
> don't, like, and they're still unhappy about it.  There's really nothing
> that can be done about this; any other decision would have had exactly the
> same consequence, just with a different set of people.

We could fix the culture.  We can choose to change our culture into one
where once we decide on something, that's decided at least until new
facts emerge.  Instead, we have chosen to have a culture where
everything can be discussed again and again, until not only is the horse
dead, but its skin is tatters and its bones meal too.

Some people in Debian who were unhappy about the decision initially did
choose to stop beating on it and instead unite and move forward.  I wish
we, collectively, agreed more that's what we'd do after such a divisive
process.

> The other point I want to make here is that the systemd discussion was
> one of the most exhausting and time-consuming things that I've ever
> been involved in.

Ditto, and even just reading those few last mails triggers something not
entirely unlike PTSD for me.

> This is some of the "being human" part that I was talking about in my
> other message.  Making people heard can be incredibly time-consuming
> and can require a ton of emotional energy, and TC members, like all
> project members, are volunteers.  Often with very limited quantities
> of time they can spend on Debian.

The TC members at least have signed up for it, having some idea of what
the work entails.  Random maintainers who are suddenly thrust into the
spotlight are much less so, and it's their emotional well-being I want
to protect at the same time as making good technical decisions.  It's
really, really hard, for many of the reasons listed in this thread.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

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

#9607 — Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

On 10/31/2017 01:36 PM, Tollef Fog Heen wrote:
> ]] Russ Allbery
> 
>> There are two primary reasons why we're continuing to discuss this.  One
>> is that the decision went a direction that a lot of people didn't, and
>> don't, like, and they're still unhappy about it.  There's really nothing
>> that can be done about this; any other decision would have had exactly the
>> same consequence, just with a different set of people.
> 
> We could fix the culture.  We can choose to change our culture into one
> where once we decide on something, that's decided at least until new
> facts emerge.  Instead, we have chosen to have a culture where
> everything can be discussed again and again, until not only is the horse
> dead, but its skin is tatters and its bones meal too.

As a user, this talk of culture and communications and sensitivity training
is baffling. To me it looks like deck chairs on the titanic.

Is it so shocking that it just won't die even after you declared dead?

I see it an existential threat, not a breakdown in Robert's rules of order.

I saw that some Debian members did not seem to believe that software authors
also "do the work," as do those who review, advocate, teach, document,
promote Debian and submit the bug reports.

Maybe they've used it for 20 years and have invested their time, careers and
businesses on Debian. Their views don't count either.

I recall the user debate being shut down before it had even started,
complete with censored posts and deleted threads, because the Maintainers
Have Spoken. Because they "did the work." Your user opinion is "noise."

I recall the slogans and catch-phrases that echoed corporate propaganda
from Red Hat. Debian under new management. Disregard Debian's own position
on init systems. We'll probably just remove it later.

The debate was fierce even within Debian, and the final vote was very close.
The 1% that decide for the rest, couldn't decide.

I can't see it from your insider perspective but from where I sit the whole
thing looks corrupt to the bone. Instead of adopting corporate slogans
start with "follow the money" and at least remove voting privileges from
paid members.

Marty

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

#9608 — Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

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

On Fri, Nov 03, 2017 at 03:24:21PM -0400, Marty wrote:
> I recall the user debate being shut down before it had even started,
> complete with censored posts and deleted threads, because the Maintainers
> Have Spoken.  Because they "did the work." Your user opinion is "noise."

> I recall the slogans and catch-phrases that echoed corporate propaganda
> from Red Hat.  Debian under new management.  Disregard Debian's own
> position on init systems.  We'll probably just remove it later.

> The debate was fierce even within Debian, and the final vote was very
> close.  The 1% that decide for the rest, couldn't decide.

So you're saying that you're a strong proponent of upstart?  It's
interesting how much support upstart has gotten only in the form of
eulogies.

But if your actual position is that Debian should have stayed with sysvinit
as the default, then you should understand *that* decision was nowhere near
close.  The Technical Committee was unanimous in their view that *either* of
systemd or upstart was preferable to sysvinit as the default init system. 
Any claim to the contrary is historical revisionism.

> I can't see it from your insider perspective but from where I sit the
> whole thing looks corrupt to the bone.  Instead of adopting corporate
> slogans start with "follow the money" and at least remove voting
> privileges from paid members.

... and this sort of nonsense is why I agree with Ian about the causes of TC
dysfunction.

The Technical Committee is a Debian-internal decision making body.  People
who are neither package maintainers nor voting members of the Debian Project
should NOT have weight given to their views, except by invitation from the
TC itself; because to have it any other way creates exactly the same failure
modes of any other Internet pile-on, where people who have no standing in
the first place expect the issue to be decided based on who can shout the
loudest, and those who are trying to make a decision grounded in the TC's
constitutional authority and duty to act in the best interest of the project
can't hear themselves think.

90% of the problem of people feeling they haven't been heard by the TC comes
from people who the TC /shouldn't actually be listening to/ investing their
time and emotional energy commenting on the process.  Removing the
opportunity to comment and the expectation of being listened to would make
for a much less frustrating process.


This doesn't address the question of Debian Developers feeling they haven't
been heard.

I'm hopeful that the other subthread can make some progress on this point.

-- 
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                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

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

#9616 — Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

On 11/03/2017 07:21 PM, Steve Langasek wrote:
> On Fri, Nov 03, 2017 at 03:24:21PM -0400, Marty wrote:

>> The debate was fierce even within Debian, and the final vote was very
>> close.  The 1% that decide for the rest, couldn't decide.
> 
> So you're saying that you're a strong proponent of upstart?  It's
> interesting how much support upstart has gotten only in the form of
> eulogies.

No eulogy was given for Debian policy 9.11 "Alternate init systems"
which is still technically in effect (unless I found an old copy).

I guess the vote I was thinking of was "general resolution not required"
narrowly edging out "support for other init systems is recommended, but
not required." in https://www.debian.org/vote/2014/vote_003 which was
anticlimactic, but seems to indicate the depth of the ideological split.

> But if your actual position is that Debian should have stayed with sysvinit
> as the default, then you should understand *that* decision was nowhere near
> close.  The Technical Committee was unanimous in their view that *either* of
> systemd or upstart was preferable to sysvinit as the default init system.
> Any claim to the contrary is historical revisionism.

I agree technically but I wonder whether strategic, ethical or social
contract issues were given sufficient weight, or if the constitution even
allows for such considerations. I don't know but this obviously would
include some regard for the wider community, including users.

Here is what I saw as a user and outsider: there was no good technical
option because Debian is not its own upstream source and evil mega-corp
jumped into the void offering a poison pill. The community then became
engulfed in a mostly pointless and crippling debate that ignored the
actual threat to its social contract. It follows a pattern I've seen
before in free software projects, including Unix in the 1980s.

Debian was caught off-guard and its governance structures did not appear
to be designed to give sufficient weight to strategic, ethical and
idealistic considerations, rather than just the bare technical issues.
The resulting infighting prevented both a strategic response and a
satisfactory resolution.

> 
>> I can't see it from your insider perspective but from where I sit the
>> whole thing looks corrupt to the bone.  Instead of adopting corporate
>> slogans start with "follow the money" and at least remove voting
>> privileges from paid members.
> 
> ... and this sort of nonsense is why I agree with Ian about the causes of TC
> dysfunction.
> 
> The Technical Committee is a Debian-internal decision making body.  People
> who are neither package maintainers nor voting members of the Debian Project
> should NOT have weight given to their views, except by invitation from the
> TC itself; because to have it any other way creates exactly the same failure
> modes of any other Internet pile-on, where people who have no standing in
> the first place expect the issue to be decided based on who can shout the
> loudest, and those who are trying to make a decision grounded in the TC's
> constitutional authority and duty to act in the best interest of the project
> can't hear themselves think.

In this case don't forget the massive internet campaign that looked like
a sponsored AstroTurf effort. I can't prove anything of course, any more
than I can prove Russians hacked US elections, but perceptions count.

I think ideally a decision making body should represent all users and
contributors somehow. I don't see how you can meet the social contract
otherwise.

Furthermore I don't think it's healthy to define all decisions in purely
technical terms in an organization defined by a social contract. I think
this may be a flaw that leads to many legalistic debates and much
browbeating, as every debate gets reduced to its simplest technical terms.

I guess it all depends on whether you think Debian is about free software
or software freedom. They're not quite the same.

I would expect the TC to weigh arguments by their validity, not just
their source, in addition to accounting for proponents' vested interests
(good or bad).

> 
> 90% of the problem of people feeling they haven't been heard by the TC comes
> from people who the TC /shouldn't actually be listening to/ investing their
> time and emotional energy commenting on the process.  Removing the
> opportunity to comment and the expectation of being listened to would make
> for a much less frustrating process.

Deleting comments and threads on -user was ham-fisted at best if that's what
you mean. To me its a sign of a breakdown of good order, not good enforcement.

I mostly agree with you but the presence of corporate paid members still
seems like an issue especially in this case. What's to keep random mega-corp
from taking over any free software project? I'd love to see a straw vote on
this topic, complete with voters' respective corporate affiliations.

> 
> 
> This doesn't address the question of Debian Developers feeling they haven't
> been heard.
> 
> I'm hopeful that the other subthread can make some progress on this point.
> 

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

#9617

Marty <martyb@ix.netcom.com> writes:

> I agree technically but I wonder whether strategic, ethical or social
> contract issues were given sufficient weight, or if the constitution
> even allows for such considerations. I don't know but this obviously
> would include some regard for the wider community, including users.

[...]

Hi Marty,

I probably shouldn't reply to more systemd discussion, but I do think this
has some relevance to the question of how to handle TC decisions more
generally, so I'm going to dive into this anyway.  I believe this is an
example of the pattern that I identified in a previous message.

What I'm seeing in your message makes me believe that you are so firmly
convinced that systemd is evil, its developers are evil, and it is a
negative effect on free software that you are unable to comprehend how
someone could disagree with you.  The only possibility is that they must
have somehow been prevented from taking those issues into account, either
by not giving them sufficient weight or because of some provision of our
governance structure, or because they were caught "off guard," or because
they're part of the corrupt conspiracy.

I was one of the Technical Committee members who was involved in this
decision.  I have, and had, absolutely no affiliation with Red Hat
whatsoever (or Ubuntu, for that matter).  I took strategic, ethical, and
social contract issues fully into account in making my decision.  They
pointed me towards systemd.  Other colleagues drew different conclusions.
We're independent human beings who arrive at different conclusions given
the same evidence.  This is reality.  Your model of governance and ethics
has to account for this, or it's useless.

I have heard all the arguments against systemd.  I understand them fully.
I was not caught off-guard.  I thought about them for months.

I believe those arguments range between valid but insufficient given the
weight of evidence in the other direction to outright incorrect.  I
believe the overall characterization of the systemd project and its effect
on Debian is factually inaccurate.

You are fully entitled to continue to disagree with me.  *But I am also
fully entitled to continue to disagree with you without being a plant or a
conspirator or a liar or a dupe.*

If your world view claims that people like me *do not exist*, your world
view is, well, wrong.  And when you continue to make arguments on the
basis that it is somehow impossible to hold the view that I, in fact,
hold, you are in effect accusing me of being unethical.  Of lying.

*This* is where I see the true source of the *ongoing* division in the
community.  It's not over the technical decision.  It's not even over the
decision-making process.  It's that some people, most (but not all) of
whom seem to be opponents of systemd, are so completely confident that
they're right and that theirs is the only ethical position possible that
they repeatedly accuse anyone who disagrees with them of bad faith.

This is horrifically destructive, and extremely demoralizing, and if
anything is going to seriously hurt the Debian project as an ongoing
collective project, it's this attitude.  Reasonable people disgree.  We
want to continue to work together anyway.  We can find ways through a lot
of different problems and challenges and disagreements as long as we can
unite around that principle.  If we can't unite around that principle,
almost any disagreement has then potential to tear us apart.

The term for this in the broader world is "assume positive intent," and
it's one of the most important characteristics for any successful
large-scale collaboration.

The broader implication of this for the TC is that the TC deals with the
most divisive issues, where people have started lining up on sides and the
tendency to assume bad faith from the other side has become very strong.
Thankfully, very few are as bad as systemd, but some will be quite heated.
The TC is in the difficult position of trying to unwind some of that type
of conflict as well as making a decision that often won't make everyone
happy.  It's extremely hard.

But one thing that the *rest* of us can do outside of the TC is to hang on
very tightly to that principle of assuming positive intent.  We're all on
the same side.  We're all trying to make Debian better.  We just disagree
how to get there.  We've all made a lot of judgement calls in the past,
and we've all been right sometimes, and we've all been *wrong* sometimes.
We can argue our sides, but at some point we just have to trust our fellow
project members and try to make the decision work.  That's what makes
Debian a collective, collaborative project rather than just a technical
assembly of packages.

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

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

#9716 — Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

On Mon, 06 Nov 2017, Russ Allbery wrote:
> *This* is where I see the true source of the *ongoing* division in the
> community.  It's not over the technical decision.  It's not even over the
> decision-making process.  It's that some people, most (but not all) of
> whom seem to be opponents of systemd, are so completely confident that
> they're right and that theirs is the only ethical position possible that
> they repeatedly accuse anyone who disagrees with them of bad faith.

As if systemd supporters aren't exhibiting the same traits ...
Just blame one side and be happy.

Norbert

--
PREINING Norbert                               http://www.preining.info
Accelia Inc.     +    JAIST     +    TeX Live     +    Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

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

#9717

Hello Norbert.

Norbert Preining - 26.12.17, 15:28:
> On Mon, 06 Nov 2017, Russ Allbery wrote:
> > *This* is where I see the true source of the *ongoing* division in the
> > community.  It's not over the technical decision.  It's not even over the
> > decision-making process.  It's that some people, most (but not all) of
> > whom seem to be opponents of systemd, are so completely confident that
> > they're right and that theirs is the only ethical position possible that
> > they repeatedly accuse anyone who disagrees with them of bad faith.
> 
> As if systemd supporters aren't exhibiting the same traits ...
> Just blame one side and be happy.

Yes, I saw blaming on both sides. At times I was blaming as well. And so in my 
surely inaccurate, subjectively colored memory did almost everyone else in a 
more or less apparent way. Also in the arguments that appeared to be purely 
technical. Also most of these as far as I remember contained a notion of "I am 
right and you are wrong".

The truth is: *Both* sides have been involved in the conflict.

Any workable solution lies beyond blame, however.

Any workable solution lies beyond "I am right and you are wrong".

This needs letting go of blame. I am not yet there, I just recently started to 
let go of blame (but in other, for me more important areas of live for now). 
Who is? Who truly let go of blaming the other side in this discussion?

Have a Merry Christmas,
-- 
Martin

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

#9719

Martin Steigerwald writes ("Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee"):
> Any workable solution lies beyond blame, however.
> Any workable solution lies beyond "I am right and you are wrong".

Traditionally Debian has a very workable approach for disagreements
over whether software X or Y is better.  (For whatever value of
"better")  Offer both and let people decide for themselves.

When things start to get really emotional and heated is when people
feel (rightly or wrongly) that such choices are being curtailed.

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]

#9720

Martin Steigerwald - 28.12.17, 13:41:
> Hello.
> 
> This is long, it may invite disagreement, but I tried my best to avoid
> triggering any hurt feelings. In case you just want to be bothered with the

do not want of course.

I proof read the mail several times, but this still slipped through my 
conscious awareness.

> past even for the purpose of figuring out ways to learn from it, I invite
> you to just skip reading the mail. There is certainly no need to relive the
> past. Given current human experience it is also not possible to change it.
> But maybe there is a way toward healing wounds.
> 
> Ian Jackson - 28.12.17, 11:20:
> > Martin Steigerwald writes ("Re: Let's Stop Getting Torn Apart by
> 
> Disagreement: Concerns about the Technical Committee"):
> > > Any workable solution lies beyond blame, however.
> > > Any workable solution lies beyond "I am right and you are wrong".
> > 
> > Traditionally Debian has a very workable approach for disagreements
> > over whether software X or Y is better.  (For whatever value of
> > "better")  Offer both and let people decide for themselves.
> 
> Sure. And it is a good approach.
> 
> Regarding Systemd/SysVInit/OpenRC this approach comes with a considerable
> cost tough as it is such a core part of the system. One cost is that a lot
> of packages link against Systemd library which is part of the reason why
> Devuan exists. Or that GNOME and to some degree other DEs without Systemd
> is somewhat challenging. Devuan developers gave up on the GNOME without
> Systemd topic for now as far as I understood.
> 
> As far as I understand it is not possible without considerable effort and
> quite some of alternative, basically duplicated packages to provide the
> choice of a truly Systemd free system within Debian. It appears to me to be
> almost like a new architecture like FreeBSD or Hurd flavors, not a
> different CPU architecture. Sure Systemd is not an operating system kernel,
> but it is a software that is really tightly coupled with one – a perfectly
> valid, but not the only possible choice made by upstream developers. But to
> provide a new architecture for this would also be considerable, heavy
> overhead. As far as I understand Devuan works a bit like that. They pull in
> a lot of packages unchanged from Debian and inject their own packages with
> some kind of an overlay mechanism. Maybe there is something for Debian
> people to learn from that approach. I did not review it closely so far.
> 
> I think it is partly this limitation that invited most of the uproar in the
> discussion some years ago.
> 
> > When things start to get really emotional and heated is when people
> > feel (rightly or wrongly) that such choices are being curtailed.
> 
> Exactly.
> 
> For those who don´t want any part of Systemd installed and used, not even
> the libraries, Debian I think is just not the suitable choice at the
> moment.
> 
> Providing that free choice would mean to think about ways how something like
> Devuan could be possible *within* the Debian project. Quite a challenge,
> but not impossible I think. Of course, Devuan people may not want to join
> the Debian project, at least not at the moment. On the other hand they do
> not provide Systemd as a choice within Devuan. They just refer to using
> Debian in case one wants to use Systemd. The other way around it could be
> perfectly valid to refer to using Devuan for those who want a Systemd free
> system.
> 
> I hope for a time where Debian and Devuan people come together to heal the
> forking. And I mean "heal" literally here. Cause there are still wounds. On
> both sides. Whether there would still be a (officially approved?) variant of
> Debian called Devuan does not matter, it could be a perfectly valid
> outcome. But to heal the wounds… I think that is important work to allow
> for that healing to happen.
> 
> A first step could be to stop accusing each other. Letting go of wanting to
> accuse the other side can help here. I do read dng mailinglists from time to
> time and some main people there often actively ask to drop Systemd debates
> or even hate speech on their lists. As far as I saw they try to be fair to
> Debian packagers as well.
> 
> Within the Debian project a first good step would be to accept the fork,
> instead of just tolerating (and probably suffering from) it (what else could
> Debian people anyway than at least to tolerate it? it is free software
> after all). Accepting the fork basically is just accepting that the past is
> they way it is. Could I let go of wanting to change the past? Especially
> when all my wanting to change the past still was not able to change it?
> 
> I read at least occasionally comments about Devuan in various Debian related
> mailing lists that suggested would not be a long lasting project and there
> would be no capable packagers / developers involved. Comments that tried to
> undermine the relevance of Devuan. A good first step could be to refrain
> from commenting in this way and open up to the possibility that some people
> there are capable packagers and testers as well and that some people have
> there have perfectly valid reasons for doing the work they do. Reasons you
> can think differently about, but still valid reasons.
> 
> Same goes for Devuan people of course. Accepting each other as they are is
> the first big, important step here.
> 
> 
> To come back to the Technical Committee topic: I think it is important to
> appreciate both sides in a dispute even when announcing the final decision.
> I don´t have all the text of the final decisions in mind. I bet tech-ctte
> members care to at least word such a final decision as neutrally or non-
> offensively as they could. But actively appreciating both sides, especially
> the side that "lost" the conflict, may be a step beyond current practice.
> Those decisions are not about right or wrong. They are about technical
> preferences.
> 
> I just reviewed some CTTE decision announcements in debian-devel-announce ml
> and while some of them include at least some rationale about the decision,
> some others are just presenting the result of the decision with strong, but
> accurate wording like "We exercise our power to decide" (including the
> various Systemd ones like 727708 and 762194). I however bet tech-ctte
> members have been completely exhausted after that discussion and decision
> process. So maybe my suggestion to appreciate both sides when announcing
> decisions… is asking for unrealistic super-human powers without other
> changes in the process.
> 
> Also are either not all CTTE´s are announced on debian-devel-announce or is
> [CTTE #741573] Debian Menu System from September 2015 really the last
> technical decision of the CTTE? According to
> 
> https://www.debian.org/devel/tech-ctte#status
> 
> it appears that there has not been an technical decision of the CTTE
> afterwards.
> 
> Thanks,


-- 
Martin

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

#9721

Hello.

This is long, it may invite disagreement, but I tried my best to avoid 
triggering any hurt feelings. In case you just want to be bothered with the 
past even for the purpose of figuring out ways to learn from it, I invite you 
to just skip reading the mail. There is certainly no need to relive the past. 
Given current human experience it is also not possible to change it. But maybe 
there is a way toward healing wounds.

Ian Jackson - 28.12.17, 11:20:
> Martin Steigerwald writes ("Re: Let's Stop Getting Torn Apart by 
Disagreement: Concerns about the Technical Committee"):
> > Any workable solution lies beyond blame, however.
> > Any workable solution lies beyond "I am right and you are wrong".
> 
> Traditionally Debian has a very workable approach for disagreements
> over whether software X or Y is better.  (For whatever value of
> "better")  Offer both and let people decide for themselves.

Sure. And it is a good approach.

Regarding Systemd/SysVInit/OpenRC this approach comes with a considerable cost 
tough as it is such a core part of the system. One cost is that a lot of 
packages link against Systemd library which is part of the reason why Devuan 
exists. Or that GNOME and to some degree other DEs without Systemd is somewhat 
challenging. Devuan developers gave up on the GNOME without Systemd topic for 
now as far as I understood.

As far as I understand it is not possible without considerable effort and 
quite some of alternative, basically duplicated packages to provide the choice 
of a truly Systemd free system within Debian. It appears to me to be almost 
like a new architecture like FreeBSD or Hurd flavors, not a different CPU 
architecture. Sure Systemd is not an operating system kernel, but it is a 
software that is really tightly coupled with one – a perfectly valid, but not 
the only possible choice made by upstream developers. But to provide a new 
architecture for this would also be considerable, heavy overhead. As far as I 
understand Devuan works a bit like that. They pull in a lot of packages 
unchanged from Debian and inject their own packages with some kind of an 
overlay mechanism. Maybe there is something for Debian people to learn from 
that approach. I did not review it closely so far.

I think it is partly this limitation that invited most of the uproar in the 
discussion some years ago.

> When things start to get really emotional and heated is when people
> feel (rightly or wrongly) that such choices are being curtailed.

Exactly.

For those who don´t want any part of Systemd installed and used, not even the 
libraries, Debian I think is just not the suitable choice at the moment.

Providing that free choice would mean to think about ways how something like 
Devuan could be possible *within* the Debian project. Quite a challenge, but 
not impossible I think. Of course, Devuan people may not want to join the 
Debian project, at least not at the moment. On the other hand they do not 
provide Systemd as a choice within Devuan. They just refer to using Debian in 
case one wants to use Systemd. The other way around it could be perfectly 
valid to refer to using Devuan for those who want a Systemd free system.

I hope for a time where Debian and Devuan people come together to heal the 
forking. And I mean "heal" literally here. Cause there are still wounds. On 
both sides. Whether there would still be a (officially approved?) variant of 
Debian called Devuan does not matter, it could be a perfectly valid outcome. 
But to heal the wounds… I think that is important work to allow for that 
healing to happen.

A first step could be to stop accusing each other. Letting go of wanting to 
accuse the other side can help here. I do read dng mailinglists from time to 
time and some main people there often actively ask to drop Systemd debates or 
even hate speech on their lists. As far as I saw they try to be fair to Debian 
packagers as well.

Within the Debian project a first good step would be to accept the fork, 
instead of just tolerating (and probably suffering from) it (what else could 
Debian people anyway than at least to tolerate it? it is free software after 
all). Accepting the fork basically is just accepting that the past is they way 
it is. Could I let go of wanting to change the past? Especially when all my 
wanting to change the past still was not able to change it?

I read at least occasionally comments about Devuan in various Debian related 
mailing lists that suggested would not be a long lasting project and there 
would be no capable packagers / developers involved. Comments that tried to 
undermine the relevance of Devuan. A good first step could be to refrain from 
commenting in this way and open up to the possibility that some people there 
are capable packagers and testers as well and that some people have there have 
perfectly valid reasons for doing the work they do. Reasons you can think 
differently about, but still valid reasons.

Same goes for Devuan people of course. Accepting each other as they are is the 
first big, important step here.


To come back to the Technical Committee topic: I think it is important to 
appreciate both sides in a dispute even when announcing the final decision. I 
don´t have all the text of the final decisions in mind. I bet tech-ctte 
members care to at least word such a final decision as neutrally or non-
offensively as they could. But actively appreciating both sides, especially 
the side that "lost" the conflict, may be a step beyond current practice. 
Those decisions are not about right or wrong. They are about technical 
preferences.

I just reviewed some CTTE decision announcements in debian-devel-announce ml 
and while some of them include at least some rationale about the decision, 
some others are just presenting the result of the decision with strong, but 
accurate wording like "We exercise our power to decide" (including the various 
Systemd ones like 727708 and 762194). I however bet tech-ctte members have 
been completely exhausted after that discussion and decision process. So maybe 
my suggestion to appreciate both sides when announcing decisions… is asking 
for unrealistic super-human powers without other changes in the process.

Also are either not all CTTE´s are announced on debian-devel-announce or is 
[CTTE #741573] Debian Menu System from September 2015 really the last 
technical decision of the CTTE? According to

https://www.debian.org/devel/tech-ctte#status

it appears that there has not been an technical decision of the CTTE 
afterwards.

Thanks,
-- 
Martin

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

#9722 — Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

On Thu, Dec 28, 2017 at 8:41 PM, Martin Steigerwald wrote:

> Providing that free choice would mean to think about ways how something like
> Devuan could be possible *within* the Debian project.

That would be quite simple once the PPAs/bikesheds/sheds proposal is
implemented; just add build profiles to disable linking against
systemd libraries (and remove other systemd deps) and a shed that
builds all those packages using the build profile.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#9723

]] Martin Steigerwald 

> Regarding Systemd/SysVInit/OpenRC this approach comes with a considerable cost 
> tough as it is such a core part of the system. One cost is that a lot of 
> packages link against Systemd library which is part of the reason why Devuan 
> exists. Or that GNOME and to some degree other DEs without Systemd is somewhat 
> challenging. Devuan developers gave up on the GNOME without Systemd topic for 
> now as far as I understood.

systemd-shim seems to still exist in testing, so presumably it works
well enough that it's not accumulating RC bugs.

As for why you want to avoid linking to particular libraries, that's
simply not how Debian works.  We generally enable all options and link
to every library possible (as long as they don't interact badly).
Personally, I don't particularly favour mysql, but I don't go out of my
way to ensure I don't have libmysqlclient (or nowadays,
libmariadbclient) installed.  It's just pointless, the cost in terms of
disk space is tiny.

[…]

> Within the Debian project a first good step would be to accept the fork, 
> instead of just tolerating (and probably suffering from) it (what else could 
> Debian people anyway than at least to tolerate it? it is free software after 
> all). Accepting the fork basically is just accepting that the past is they way 
> it is. Could I let go of wanting to change the past? Especially when all my 
> wanting to change the past still was not able to change it?

I don't know what you mean by accepting the fork.  It's a fork.  Forking
is fine and those folks interested in doing something that doesn't fit
in Debian proper (whether that's removing specific bits they object to
or something else) are free to do so.

[…]

> Also are either not all CTTE´s are announced on debian-devel-announce or is 
> [CTTE #741573] Debian Menu System from September 2015 really the last 
> technical decision of the CTTE?

https://lists.debian.org/debian-devel-announce/2017/07/msg00006.html is
an example of one from this summer.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

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

#9600

Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee"):
> I am discussing how we handle conflict because I hope we can do a better
> job of helping  people feel valued even when we do not agree with their
> technical positions.

You've perhaps heard me say this before, but I think the TC process
lacks structure and that if the TC set out the process more formally,
things might go less awry.  (And also it would involve less of an
investment of energy by all the partipants, particularly the
respondents to a complaint.)

One of the most toxic things that can happen in any kind of dispute is
for there not to be a clear understanding of what the rules are,
within which the dispute will be conducted.  Ie, who is allowed to do
and say what, and when.

When people disagree about the metarules, community disintegrates
because people feel that not only are their opponents disregarding
their needs, but they are also playing foul.


I know that some people disagree, but I think that the TC should take
on much more of the trappings of other formal dispute resolution
mechanisms that we find in wider society.  Particularly, the TC should
be more like a civil court or tribunal.

Courts are of course stressful, but I think that stress is usually the
result of the underlying dispute.  (Courts in some jurisdictions are
awful, too, of course, and I'm not suggesting we set up professional
advocates with a vested interest in prolonging and exacerbating
disagreements...)

One big advantage of court-like formality is is that it provides
neutral (and possibly even constructive) ways to express and handle
the disagreement.  And of course it can avoid arguments over the
ground rules.

There are other models: mediation, perhaps.  But mediation is just
facilitated negotiation, and explicitly excludes the question of
justice or rightness.  What really matters for the outcome of
mediation is not who has the best arguments, but what are the parties'
"best alternatives to negotiation".

So the TC should formally adopt rules of procedure, saying how and
when issues should be brought to the TC, and how the TC will handle
them.  The rules should cover questions of when TC members should use
their ability to call for votes, and add amendments.  They should say
what interval is normally appropriate before asking the TC for help.
The rules will need to be bent on occasion, of course - but the rules
themselves should say who can grant permission to bend them.

The TC rules could also limit the email discussion, at least by
default - one of the most exhausting things about the TC right now is
the never-ending email threads.

It would also IMO be a good idea for the TC to explicitly adopt some
"form letters" that should be used in various circumstances.  If there
were a standard TC-approved text for the message saying "I feel
strongly enough about this, and you don't seem to agree, so I think I
will ask the TC for help soon" then that text could be made suitably
collegiate and refined over time, and there would be no arguments
about the tone of someone's email.


> I was not planning on discussing systemd again.

Thanks.  I don't think doing so is going to be illuminating.  It will
just reopen wounds.

Ian.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web