Considerations on a gitlab-style forge

Considerations on a gitlab-style forge

[Claudio Bantaloukas]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

Hi,
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/  ?

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.

Re: Considerations on a gitlab-style forge

[Mark Wielaard]

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/

Cheers,

Mark

Re: Considerations on a gitlab-style forge

[Claudio Bantaloukas]

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.

Re: Considerations on a gitlab-style forge

[Frank Ch. Eigler]

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.

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

> - what others are working on

(You cannot know that. :-)

> - that doesn't feel like Donald Norman's proverbial teapot!

No comment!

- FChE

Re: Considerations on a gitlab-style forge

[Claudio Bantaloukas]

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.