public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
From: Claudio Bantaloukas <Claudio.Bantaloukas@arm.com>
To: "Frank Ch. Eigler" <fche@redhat.com>,
	Overseers mailing list <overseers@sourceware.org>
Cc: Mark Wielaard <mark@klomp.org>
Subject: Re: Considerations on a gitlab-style forge
Date: Fri, 12 Apr 2024 17:37:11 +0000	[thread overview]
Message-ID: <19d32308-2b9f-42f6-bfed-e3c75d69aaa7@arm.com> (raw)
In-Reply-To: <20240411222324.GA12335@redhat.com>



On 11/04/2024 23:23, Frank Ch. Eigler wrote:
> Hi -
>
>> Thank you for answering, I've been trying to come up with a high level
>> reason why something about those forges is desirable to people like me
>> and the best I could come up with is this.
>>
>> Having a single place where a developer can see:
>> [...]
>> - any code review comments their fellow developers may have
>
> Yeah, that seems to be the main benefit, easier than email threads.

Trying to be the devil's advocate, I would argue that a lot of
developers prefer email threads, so, if taken on its own, that's not a
compelling argument that is likely to reach consensus.
Which is why I'm making the argument that all of the things I mentioned
must be in one place, with adequate ways of searching for required
information.

>> - whether these changes are likely to break things for others
>
> That's hard to know unless you share code & inter-merge, which is not
> automatic in web-forge type systems, and can be done via personal or
> development branches in the current system too.

Indeed, making a useful CI system is about as hard as making a useful
suite of tests. It's hard, but not impossible.

For an example of a not too bad system, see this merge request in the
cmake project: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7400
There's sanity check automation that runs on all changes and a bot,
invoked by vetted people, that allows running expensive checks.

A similar example on a Libre forge (minus the bot):
https://codeberg.org/forgejo/forgejo/pulls/3156

>> - what others are working on
>
> (You cannot know that. :-)

Indeed browsing gcc-patches is not for the faint of heart! I meant being
able to see other people's open merge requests, something that I've
found valuable in the past.

Cheers,
Claudio
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

      reply	other threads:[~2024-04-12 17:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-09  9:35 Claudio Bantaloukas
2024-04-10 13:57 ` Mark Wielaard
2024-04-11 13:17   ` Claudio Bantaloukas
2024-04-11 22:23     ` Frank Ch. Eigler
2024-04-12 17:37       ` Claudio Bantaloukas [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=19d32308-2b9f-42f6-bfed-e3c75d69aaa7@arm.com \
    --to=claudio.bantaloukas@arm.com \
    --cc=fche@redhat.com \
    --cc=mark@klomp.org \
    --cc=overseers@sourceware.org \
    /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).