public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Joel Brobecker <brobecker@adacore.com>,
	mark@klomp.org, aburgess@redhat.com, luis.machado@arm.com,
	simark@simark.ca, gdb@sourceware.org
Subject: Re: Any concrete plans after the GDB BoF?
Date: Thu, 16 Feb 2023 17:31:33 +0400	[thread overview]
Message-ID: <Y+4wNbjdMUZNjzcl@adacore.com> (raw)
In-Reply-To: <83zg9d7rfl.fsf@gnu.org>

> > There are not a whole lot of hosting platforms out there, so my concern
> > is that, by making email integration a requirement, you're automatically
> > eliminating a number of solutions which could answer your requirements
> > just as well, only just differently, and from there, lose some great
> > features out there.
> 
> Please also take into consideration the other side of this: switching
> to a web-based discussions makes participation via email all but
> impractical.  People tend to answer short answers without quoting the
> context, assuming that all the context is visible in the web form
> anyway, and that makes email messages undecipherable.  I follow one
> such repository, which uses GitHub, for more than a year, and it is
> very frustrating.
> 
> So if good support for email is not a requirement, we need to consider
> the consequences of basically abandoning email entirely.

FTAOD, I am not saying that we must abandon email.

I understand what everyone is saying, and I understand the benefits
of email. But aren't we allowing our own experience to unfairly bias
the list of requirements?

Rather than say "email is nice because it provides those nice
properties" therefore "let's keep emails", I think we should say
"let's investigate any solution that preserve the nice properties",
including those that don't do via email. Otherwise, you're putting
the cart before the horses.

If we think that web-based is necessarily bad and hopeless, then
we're closing ourselves to some options where this might not be true.
All I'm saying is that we need to keep an open mind, rather than
corner ourselves by hanging on to one particular tool. You don't
need the tool, you need what the tool does for you.

If we allow ourselves to consider the idea that what's important
is the ease of having discussions, and that perhaps there might be
systems out there where discussions can be fluently had, read,
and reread later, or if we consider the idea that a certain amount
of sacrifice in this area in exchange for a significant-enough amount
of benefits is worth considering, then we open our mind to evaluating
more fairly a number of options which may surprise us, and be a net
gain for us and for the community.

-- 
Joel

  reply	other threads:[~2023-02-16 13:31 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 10:47 Luis Machado
2022-10-28 16:16 ` Simon Marchi
2022-10-28 16:51   ` John Baldwin
2022-10-28 16:54     ` Simon Marchi
2022-10-31  9:28   ` Luis Machado
2022-10-31 13:17     ` Simon Marchi
2022-10-31 13:37       ` Joel Brobecker
2022-10-31 14:15         ` Simon Marchi
2022-10-31 17:31           ` Joel Brobecker
2023-02-11 17:13           ` Andrew Burgess
2023-02-12 12:43             ` Mark Wielaard
2023-02-13 11:54               ` Andrew Burgess
2023-02-13 12:52                 ` Luis Machado
2023-02-13 14:24                   ` Tom Tromey
2023-02-13 14:42                     ` Luis Machado
2023-02-13 15:13                   ` Andrew Burgess
2023-02-13 15:23                     ` Luis Machado
2023-02-14  5:48                       ` Joel Brobecker
2023-02-15 14:47                         ` Andrew Burgess
2023-02-16  4:14                           ` Joel Brobecker
2023-02-16  9:51                           ` Mark Wielaard
2023-02-16 10:16                             ` Joel Brobecker
2023-02-16 11:58                               ` Eli Zaretskii
2023-02-16 13:31                                 ` Joel Brobecker [this message]
2023-02-16 15:23                                   ` Eli Zaretskii
2023-02-14 13:07                   ` Mark Wielaard
2023-02-14 14:23                   ` Pedro Alves
2023-02-14 13:00                 ` Mark Wielaard
2023-02-15 14:36                   ` Andrew Burgess
2023-02-13 14:05             ` Tom Tromey
2022-12-15 10:17     ` Luis Machado
2023-01-01 22:02     ` Mark Wielaard
2023-01-20 17:30       ` Tom Tromey
2023-01-20 20:30         ` Tom Tromey
2023-01-27 15:50           ` Lancelot SIX
2023-01-27 23:50             ` Tom Tromey
2023-01-30 17:43               ` Lancelot SIX
2023-01-30 18:46                 ` Mark Wielaard
2023-01-30 21:08                   ` Tom Tromey
2023-02-04 11:36                     ` Mark Wielaard
2023-01-31 10:00                   ` Lancelot SIX
2022-12-13  2:48 ` Frank Ch. Eigler
2023-02-16  8:53 anix

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=Y+4wNbjdMUZNjzcl@adacore.com \
    --to=brobecker@adacore.com \
    --cc=aburgess@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=mark@klomp.org \
    --cc=simark@simark.ca \
    /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).