Updated Sourceware infrastructure plans

[Benson Muite]

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.