Dragan Simic <[email protected]> writes: > On 2025-09-28 22:13, Arsen Arsenović wrote: >> Dragan Simic <[email protected]> writes: >>> On 2025-09-28 19:53, Collin Funk wrote: >>>> Arsen Arsenović <[email protected]> writes: >>>>> Note that we're considering using Sourceware-hosted Forgejo (which >>>>> Codeberg maintains and uses) for the GNU toolchain, with the advantages >>>>> above (especially automation-related advantages) in mind. See >>>>> https://gcc.gnu.org/wiki/ForgeExperiment >>>> Have any projects begun using this yet? I am a glibc committer, and as >>>> far as I can tell no one has begun using it [1]. >>>> Maybe gcc and/or binutils have started experimenting with it? I do not >>>> follow their development closely. >>>> Collin >>>> [1] Well maybe they do for the Web UI which is nicer than gitweb and has >>>> features like code search. >>> If I understood the forge experiment [2] correctly, it implements a >>> GitHub- style workflow that allows people to use pull requests, but >>> the end result are actually patches sent to the "old-school" mailing >>> lists? >> This is the case for length of the experiment, the copy on the forge is >> read-only in a sense, and all patches merged are specified to be sent >> onto the mailing list, ergo people have to do it anyway currently. >> The end goal, to my understanding, is to not duplicate work, and skip >> the ML step, eventually. > > I don't see that written anywhere, but maybe I'm wrong.
That was my interpretation of the zeitgeist last Cauldron. I realized after writing this that Cauldron is currently going on (sadly, I'm not in attendance this year), and this topic is being discussed again. I wonder if there's been developments. >>> If so, I find such an approach nearly perfect, because it merges the >>> best of both worlds and frees the new contributotrs from the need to >>> set up git-send-email(1), for example, if they prefer not to. >>> That's pretty much the same as what GitGitGadget [3] already allows, >>> which Git uses as an option for submitting patches. I've always truly >>> loved GitGitGadget's presence as an option, because it keeps the >>> mailing lists as the primary workflow, while it removes the proverbial >>> entry barrier for the contributors who actually prefer to use pull >>> requests. To phrase it a bit differently, variety is the proverbial >>> spice of life. >> I agree that GGG fixes the "new contributor" issue. >> But, that's the less important part of this experiment IMO. > > Well, GitGitGadget is an "experiment" that's been running successfully > for many years, in parallel to the mailing list. To clarify, by experiment I mean the ForgeExperiment as described by the GCC wiki. -- Arsen Arsenović
signature.asc
Description: PGP signature
