On Tue, 2024-11-19 at 21:45 +0100, Mark Wielaard wrote: > Hi, > > Random request... > > On Tue, Nov 19, 2024 at 11:14:38AM -0500, David Malcolm wrote: > > > Here's the updated patch and answers below. > > > > > > (GitHub link if you find it easier for review: > > > https://github.com/antoyo/libgccjit/pull/5) > > > > > > Thanks. > > > > Thanks; I looked over the patch via the above link and it looks > > good to > > me for trunk. > > Since we now have an experimental forge at > https://forge.sourceware.org > would it be an idea to use that for such reviews? > > We would love to get feedback on the forge idea (but ideally one > based > on Free Software and under community control). > > See for some more background: > https://gcc.gnu.org/wiki/ForgeExperiment > > You could sign up with your gcc ids (antoyo@gcc... or > dmalcolm@gcc...). > > Please sent requests for help, feedback (good or bad) to the forge > mailinglist: https://sourceware.org/mailman/listinfo/forge (You don't > need to subscribe unless you want to be part of the forge community.)
Thanks Mark. I'm finding it a *lot* easier to manage patch reviews using github rather than mailing list threads: specifically: the github web UI has: (a) convenient metadata tags that make it clear "who has the ball" for each patch, integrated with: (b) really nice UX for viewing and commenting on patches which the mailing-list plus patchwork approach is far inferior to IMHO. I hope the forge instance has similar capabilities for both (a) and (b). One downside of the https://github.com/antoyo/libgccjit/pull workflow for (a) is that I can't edit the labels when I review things (though maybe Antoni can give me access to that?) ...but yeah, it's not ideal to be using a closed source site for this. That said, Antoni and I have things split between two places already: the mailing lists and his github. I'd be up for doing it in the forge instance instead, but arguably we'd then be splitting things into *three* places... gahhh!!!! AIUI Antoni is already using github for interacting with the rustc project, so it might be considerably easier for him to stick to github; I'm feeling guilty about my crappiness at patch review so I feel I don't have much of a moral high ground here to push for a non- proprietary tool. Dave
