* Considerations on a gitlab-style forge @ 2024-04-09 9:35 Claudio Bantaloukas 2024-04-10 13:57 ` Mark Wielaard 0 siblings, 1 reply; 5+ messages in thread From: Claudio Bantaloukas @ 2024-04-09 9:35 UTC (permalink / raw) To: overseers [-- 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Considerations on a gitlab-style forge 2024-04-09 9:35 Considerations on a gitlab-style forge Claudio Bantaloukas @ 2024-04-10 13:57 ` Mark Wielaard 2024-04-11 13:17 ` Claudio Bantaloukas 0 siblings, 1 reply; 5+ messages in thread From: Mark Wielaard @ 2024-04-10 13:57 UTC (permalink / raw) To: Claudio Bantaloukas via Overseers; +Cc: Claudio Bantaloukas 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Considerations on a gitlab-style forge 2024-04-10 13:57 ` Mark Wielaard @ 2024-04-11 13:17 ` Claudio Bantaloukas 2024-04-11 22:23 ` Frank Ch. Eigler 0 siblings, 1 reply; 5+ messages in thread From: Claudio Bantaloukas @ 2024-04-11 13:17 UTC (permalink / raw) To: Mark Wielaard, Claudio Bantaloukas via Overseers 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Considerations on a gitlab-style forge 2024-04-11 13:17 ` Claudio Bantaloukas @ 2024-04-11 22:23 ` Frank Ch. Eigler 2024-04-12 17:37 ` Claudio Bantaloukas 0 siblings, 1 reply; 5+ messages in thread From: Frank Ch. Eigler @ 2024-04-11 22:23 UTC (permalink / raw) To: Overseers mailing list; +Cc: Mark Wielaard, Claudio Bantaloukas 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Considerations on a gitlab-style forge 2024-04-11 22:23 ` Frank Ch. Eigler @ 2024-04-12 17:37 ` Claudio Bantaloukas 0 siblings, 0 replies; 5+ messages in thread From: Claudio Bantaloukas @ 2024-04-12 17:37 UTC (permalink / raw) To: Frank Ch. Eigler, Overseers mailing list; +Cc: Mark Wielaard 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-04-12 17:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-04-09 9:35 Considerations on a gitlab-style forge 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 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).