Automated patch emails for Rust front-end commits

[Arthur Cohen]

Hi NightStrike, Sam,

Apologies for missing your original email NightStrike. Like Sam said, 
the amount of effort to completely move to the Forge would be non 
negligeable, and it makes sense to continue improving our current GitHub 
pipeline. I don't personally have the time to translate all of our 
workflows to the CI system that the forge uses and I do not want to work 
on migrating from GitHub to ForgeJo.

While I greatly dislike GitHub, it is a great social platform for 
contributor outreach and communication with people who might be 
unfamiliar with how GCC works. We will not be moving away from GitHub 
anytime soon as it helped us get many contributors, GSoC students, and 
helpful comments from core rustc developers. I would be very happy to 
use the forge alongside GitHub and benefit from it, and I'm looking 
forward to doing so.

Best,

Arthur

On 11/11/25 4:38 AM, Sam James wrote:
> NightStrike via Gcc <gcc@gcc.gnu.org> writes:
> 
>> On Mon, Nov 10, 2025 at 8:04 PM Arthur Cohen <arthur.cohen@embecosm.com> wrote:
>>>
>>> Hi everyone,
>>>
>>> We recently had a chat with Richi about what the Rust front-end could do
>>> to increase the interactions with the GCC side of our community. Richi
>>> pointed out that it would be good for patches to show up on the mailing
>>> list as they are merged in our development repository, rather than in
>>> batches whenever we send a patchset upstream.
>>>
>> [...]
>>> If anyone has anything else they'd like to see us do, please let me
>>> know! We are happy to work on anything that will increase the
>>> communication and/or interaction between the Rust side and the GCC side
>>> of our little front-end.
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-October/699320.html
> 
> I see that as orthogonal to this. The forge is also still in an
> experimental state but work is ongoing to get out of that (lots of
> discussion at Cauldron).
> 
> If/when it is out of an experimental state, it may still not make sense
> for gccrs to move entirely there (though it may have a presence
> there). We don't currently have many CI runners available on the forge
> either.
> 
> I don't think putting a new pipeline together (i.e. some new github
> actions glue) really translates into the same amount of effort as moving
> to a new hosting location, especially when that hosting location isn't
> fully ready to take on projects for the long-term yet.
> 
> I think we should support them in spending as much time as possible in
> working on getting the implementation ready to build the stdlib and
> while small practical requests should be made to them, I don't consider
> this one of those.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1B3465B044AD9C65.asc
Type: application/pgp-keys
Size: 3143 bytes
Desc: OpenPGP public key
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20251112/f1c270f1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20251112/f1c270f1/attachment.sig>