>> 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?
