public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Benson Muite <benson_muite@emailplus.org>
To: Overseers mailing list <overseers@sourceware.org>,
	Mark Wielaard <mark@klomp.org>
Cc: Ben Boeckel <ben.boeckel@kitware.com>,
	Jeff Law <jeffreyalaw@gmail.com>,
	Joseph Myers <josmyers@redhat.com>,
	libc-alpha@sourceware.org, Jason Merrill <jason@redhat.com>,
	gcc@gcc.gnu.org, gdb@sourceware.org,
	Sergio Durigan Junior <sergiodj@sergiodj.net>,
	binutils@sourceware.org, Tom Tromey <tom@tromey.com>
Subject: Re: Updated Sourceware infrastructure plans
Date: Sun, 5 May 2024 08:22:12 +0300	[thread overview]
Message-ID: <ba50fa0b-79d3-9361-362b-e24d6f7692c8@emailplus.org> (raw)
In-Reply-To: <ZjaS3P1MJ7naDNuW@farprobe>

On 04/05/2024 22.56, Ben Boeckel via Overseers wrote:
> On Wed, May 01, 2024 at 23:26:18 +0200, Mark Wielaard wrote:
>> On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote:

> 
>> At the moment though the only thing people seem to agree on is that
>> any system will be based on git. So the plan for now is to first setup
>> a larger git(olite) system so that every contributor (also those who
>> don't currently have commit access) can easily "post" their git
>> repo. This can then hopefully integrate with the systems we already
>> have setup (triggering builder CI, flag/match with patchwork/emails,
>> etc.) or any future "pull request" like system.

It may be helpful to determine minimal forge features that people find
useful and make these into a standard.  This would enable
interoperability and automation.  In addition to Git, other tools such
as Sapling, Mercurial, Fossil and Subversion are also used and are more
suitable for many projects.

> 
> As a fellow FOSS maintainer I definitely appreciate the benefit of being
> email-based (`mutt` is far better at wrangling notifications from
> umpteen places than…well basically any website is at even their own),
> but as a *contributor* it is utterly opaque. It's not always clear if my
> patch has been seen, if it is waiting on maintainer time, or for me to
> do something. After one review, what is the courtesy time before pushing
> a new patchset to avoid a review "crossing in the night" as I push more
> patches? Did I get everyone that commented on the patch the first time
> in the Cc list properly? Is a discussion considered resolved (FWIW,
> Github is annoying with its conversation resolution behavior IMO;
> GitLab's explicit closing is much better). Has it been merged? To the
> right place? And that's for patches I author; figuring out the status of
> patches I'm interested in but not the author of is even harder. A forge
> surfaces a lot of this information pretty well and, to me, GitLab at
> least offers usable enough email messages (e.g., discussions on threads
> will thread in email too) that the public tracking of such things is far
> more useful on the whole.

This is an area that also needs standardization of important
functionality.  Some method of archiving the content is also helpful -
email does this well but typically does not offer  dashboard. Sourcehut
makes reading threads using the web interface very easy.

Web interfaces are difficult to automate, but friendlier for occasional
use and encouraging new contributions.  Tools separate from the version
control system such as Gerrit, Phabricator, Rhode Code and Review Board
also enable discussion management and overview.



  reply	other threads:[~2024-05-05  5:23 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17 23:27 Mark Wielaard
2024-04-18  6:04 ` Thomas Koenig
2024-04-18  8:14   ` FX Coudert
2024-04-18  9:01     ` Christophe Lyon
2024-04-18 11:38     ` Janne Blomqvist
2024-04-18 12:01       ` Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans) Tobias Burnus
2024-04-18 12:32         ` Martin Uecker
2024-04-19  9:35   ` Updated Sourceware infrastructure plans Jonathan Wakely
2024-04-18 15:56 ` Joseph Myers
2024-04-18 17:37   ` Frank Ch. Eigler
2024-04-18 17:54     ` Joseph Myers
2024-04-18 18:29     ` Matt Rice
2024-04-22 15:39     ` Tom Tromey
2024-04-23  2:55       ` Jason Merrill
2024-04-23  3:12         ` Simon Marchi
2024-04-23  3:24         ` Tom Tromey
2024-04-23  3:51           ` Jason Merrill
2024-04-23  8:56             ` Mark Wielaard
2024-04-23  9:39               ` Richard Earnshaw (lists)
2024-04-23 15:08             ` Tom Tromey
2024-04-23 15:25               ` Simon Marchi
2024-04-24  8:49                 ` Aktemur, Tankut Baris
2024-04-23  4:06           ` Ian Lance Taylor
2024-04-23  9:30           ` Richard Earnshaw (lists)
2024-04-23 13:51             ` Ian Lance Taylor
2024-05-01 19:15           ` Jeff Law
2024-05-01 19:38             ` Jonathan Wakely
2024-05-01 20:20               ` Mark Wielaard
2024-05-01 20:53                 ` Tom Tromey
2024-05-01 21:04                   ` Simon Marchi
2024-05-02 15:35                     ` Pedro Alves
2024-05-02 23:05                       ` Fangrui Song
2024-05-07 16:17                         ` Joseph Myers
2024-05-10 10:43                           ` Ben Boeckel
2024-05-01 20:04             ` Jason Merrill
2024-05-01 21:26               ` Mark Wielaard
2024-05-01 22:01                 ` Sergio Durigan Junior
2024-05-02 12:54                 ` Claudio Bantaloukas
2024-05-02 15:33                 ` Pedro Alves
2024-05-03  2:59                   ` Ian Lance Taylor
2024-05-04 19:56                 ` Ben Boeckel
2024-05-05  5:22                   ` Benson Muite [this message]
2024-05-06 13:58                     ` Ben Boeckel
2024-05-07 16:26                   ` Joseph Myers
2024-05-01 21:38               ` Jeff Law
2024-05-02  6:47                 ` Richard Biener
2024-05-02 11:29                   ` Ian Lance Taylor
2024-05-02 14:26                   ` Simon Marchi
2024-05-02 11:45                 ` Mark Wielaard
2024-05-01 22:56               ` Tom Tromey
2024-04-23 10:34         ` Florian Weimer
2024-04-22 10:01   ` Mark Wielaard
2024-04-22 13:23     ` Joseph Myers
2024-04-19  9:33 ` Jonathan Wakely
2024-04-22 10:24   ` Mark Wielaard
2024-04-22 11:40     ` Jonathan Wakely
2024-04-23  0:48   ` Frank Ch. Eigler

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=ba50fa0b-79d3-9361-362b-e24d6f7692c8@emailplus.org \
    --to=benson_muite@emailplus.org \
    --cc=ben.boeckel@kitware.com \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --cc=jason@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=josmyers@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=mark@klomp.org \
    --cc=overseers@sourceware.org \
    --cc=sergiodj@sergiodj.net \
    --cc=tom@tromey.com \
    /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).