public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@gnu.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: Alexandre Oliva via Libc-alpha <libc-alpha@sourceware.org>,
	"Carlos O'Donell" <carlos@redhat.com>,
	Jakub Jelinek <jakub@redhat.com>, Andreas Schwab <schwab@suse.de>,
	Joseph Myers <joseph@codesourcery.com>,
	Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
Subject: Re: [Action Required] glibc decision to use CTI services.
Date: Mon, 04 Sep 2023 03:09:33 -0300	[thread overview]
Message-ID: <or5y4qjwpu.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <87edjjcxg5.fsf@oldenburg.str.redhat.com> (Florian Weimer's message of "Thu, 31 Aug 2023 12:34:18 +0200")

On Aug 31, 2023, Florian Weimer <fweimer@redhat.com> wrote:

> I'm not sure why “GNU” should have a say in this

GNU libc is part of the GNU Project.  GNU libc appointed maintainers
have formally accepted responsibilities to operate in line with the
project in our capacity as GNU maintainers.

We're being called to make a decision, as GNU maintainers, that pretty
much alienates from GNU the package entrusted to us.

Any legitimate decision-making powers we maintainers have over GNU libc,
it was delegated to us by GNU, conditioned on our observance of these
responsibilities.  We're expected to make sure that contributions that
are accepted advance the project's goals, and to ask for guidance when
there's uncertainty.

How could one possibly imagine that GNU should *not* have a say on it?

> How would that even work?

Ask some GNU-appointed maintainer you trust who hasn't gone rogue, they
should be able to convey that answer to you in a way you wouldn't doubt
as much as if it came from me.

> I think we don't have consensus what GNU's current decision-making
> structure looks like.

I realize there are people who'd like the GNU leadership structure to be
different from what it is, but that's at the peril of delegitimizing
their own roles appointed through the existing structure.

Anyhow, GNU mission and structure are not matters for consensus among
whoever wishes to share their opinions: those who agree to volunteer to
a cause don't get to redefine the cause, and making it so that they did
would make the cause too vulnerable to dilution and occupation.  Even
majority votes among the general population are a poor choice for
promoting social change: it captures where most of the population *is*,
which is by definition the opposite of social *change*.

GNU mission and structure are what they have been since long before any
of us started contributing to it.  They were designed to be reasonably
robust against hostile takeover, power grabs and attempts to dilute
GNU's goals or otherwise turn GNU into something else, while enabling
GNU to accept contributions from people and organizations who don't
share its values and goals.

Historically, most contributors haven't shared our values or goals, and
enabling them to reset our course would have been the surest way to get
none of the social change we hope to achieve.  Instead of striving for
an overall average likely influenced by extraneous interests, we're
better served by the strongest commitment to the cause, to the goals, to
the values, and the deepest understanding of the challenges we face.

That diversity of values, alignments, motivations and opinions among
potentially-misaligned contributors also makes room for some tension
when people and organizations attempt to project or even impose by force
onto GNU their own extraneous stances, without regard for the
decision-making structure, for why it is as it is, or for what we're up
for, up against, or up to.

These tensions are sometimes hard to navigate, but they strike an IMHO
ideal balance between accepting contributions from anyone willing to
contribute to the cause, and rejecting changes that would be detrimental
to the cause.

-- 
Alexandre Oliva, happy hacker                    https://FSFLA.org/blogs/lxo/
   Free Software Activist                           GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice but
very few check the facts.  Think Assange & Stallman.  The empires strike back

      reply	other threads:[~2023-09-04  6:10 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <b84ea4a5-651a-1a4c-06c8-e9ade4b7d702@redhat.com>
2023-08-30 17:19 ` Alexandre Oliva
2023-08-30 17:31   ` Joseph Myers
2023-08-31 19:59     ` Paul Eggert
2023-09-01  6:03       ` Sam James
2023-09-01  8:55         ` Florian Weimer
2023-09-01  9:02           ` Sam James
2023-09-01  9:21             ` dmarc, dkim and From rewriting Mark Wielaard
2023-09-01 11:52               ` Florian Weimer
2023-09-01  9:03           ` [Action Required] glibc decision to use CTI services Andrew Pinski
2023-09-01 11:49             ` Florian Weimer
2023-09-01 13:32           ` Frank Ch. Eigler
2023-09-01 12:30         ` Siddhesh Poyarekar
2023-09-01 14:54           ` Paul Eggert
2023-09-01 16:08             ` Siddhesh Poyarekar
2023-09-01 15:01           ` Sam James
2023-09-01 16:19             ` Frank Ch. Eigler
2023-09-01 16:30             ` Siddhesh Poyarekar
2023-09-02 18:25             ` Mark Wielaard
2023-09-01  9:08       ` Mark Wielaard
2023-09-03  6:31       ` Alexandre Oliva
2023-09-27 13:49       ` Carlos O'Donell
2023-10-04  0:09         ` Paul Eggert
2023-09-01 15:09     ` Alexandre Oliva
2023-09-27 13:50     ` Carlos O'Donell
2024-02-13  0:43       ` Carlos O'Donell
2024-02-19 21:22         ` Alexandre Oliva
2024-02-19 22:03           ` DJ Delorie
2024-02-20  1:49             ` Mark Wielaard
2024-02-20  3:01             ` Alexandre Oliva
2023-08-31  8:37   ` Mark Wielaard
2023-09-01 15:08     ` Alexandre Oliva
2023-08-31 10:34   ` Florian Weimer
2023-09-04  6:09     ` Alexandre Oliva [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=or5y4qjwpu.fsf@lxoliva.fsfla.org \
    --to=oliva@gnu.org \
    --cc=carlos@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).