Re: Considerations on a gitlab-style forge

[Claudio Bantaloukas <claudio.bantaloukas@arm.com>]

On 4/10/2024 2:57 PM, Mark Wielaard wrote:
> Hi Claudio,
>
> On Tue, 2024-04-09 at 09:35 +0000, Claudio Bantaloukas via Overseers
> wrote:
>> I recently read your emails in the binutils mailing list and, since feedback was requested, here's some.
>> I miss the high level feature caleld pull requests in github and merge requests in gitlab.  For licensing reasons these two projects are not ok.
>> I just saw https://sfconservancy.org/GiveUpGitHub/
>> Have the overseers considered adding https://github.com/go-gitea/gitea or its fork https://forgejo.org/  ?
>
> Sort answer, no. But that doesn't mean it cannot happen.
> Longer answer is that different people have different ideas about what
> a "pull-request model" precisely is. In general since most core
> toolchain and developer tool projects on Sourceware are highly invested
> in an email workflow we have been working on services that work best
> with that. See for example the Sourceware roadmap from a couple of
> years back that explains the why behind the current services:
> https://gnu.wildebeest.org/blog/mjw/2022/06/22/sourceware-gnu-toolchain-infrastructure-roadmap/
>
> Recently Tom and Jeff expressed interest in a "pull-request model"
> https://inbox.sourceware.org/libc-alpha/9124eadc81726959bb775e913ce6e6aaa5e51e45.camel@klomp.org/
>
> Maybe they can help guide us towards that model and the necessary
> services to implement it. We could for example resurrect the gerrit
> setup (assuming that is how people envision the "pull-request model" to
> work). Or we could indeed look into other services like gitea, forgejo,
> pagure or sourcehut.
>
> Note that there is a mirror on sr.ht already that you could play with
> https://sr.ht/~sourceware/binutils-gdb/

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:
- the change they are working on in the context of the wider project
- any code review comments their fellow developers may have
- whether these changes are likely to break things for others
- what others are working on
- that doesn't feel like Donald Norman's proverbial teapot!

Would this make sense to others?

>
> Cheers,
>
> Mark

--
Claudio Bantaloukas
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.