gcc11-devel and our buildbots

[Christopher Nielsen]

>> It seems like we’re updating this port at least weekly. With the result being that our Intel buildbots are routinely bogged down for a long time, sometimes as long as 4-5 hours.
>> 
>> While I understand that we want to follow upstream’s progress - particularly for the ARM version - is this really necessary for Intel?
> 
> The reality is even worse, as libgcc-devel takes as long to build - if not longer - than gcc-devel. So net-net, our Intel buildbots are routinely being tied up for 8+ hours on each update.

After sleeping on this, it’s apparent that my e-mails from yesterday weren’t quite as constructive as one might hope. And they could also be construed as critical, which wasn’t my intention.

So let me start with this: I totally respect - and appreciate! - that we’re closely following upstream. Particularly if anyone is using ‘gccdevel’ for cross-compilation, targeting evolving architectures like RISC-V. (And support for things like the latter are likely occurring at a rapid pace.)

That said, I’m wondering whether it might make sense to curb our updates slightly... perhaps limiting them to a twice-monthly update cadence? That would still ensure that we’re able to provide leading-edge toolchain components, without quite as much impact to our buildbot resources.

Ultimately, I’m not opposed to weekly updates, particularly if there is a strong need and/or demand for it. But it would help to know how we decide on which commit we choose, when updating such a port. For example, does upstream bless beta releases on a certain day of the week, and/or with certain commits? Etc.

Thoughts on all of the above?