Regressions getting more common

[Kamil Rytarowski]

Hi Luis,

I talked to Sergio and his ex-boss from Red Hat as I proposed to
maintain the CI infrastructure on behalf of my new company - Moritz
Systems (www.moritz.systems).

Unfortunately RH currently cannot rearrange the budgets, but how about
Linaro? We could spare a dedicated developer full-time or part-time to
monitor the reports and maintain the infrastructure.

We are experienced in maintaining CI infrastructure for years in the BSD
distribution development is a heavy CI workflow (multiple CPUs, multiple
tests, emulators, real machines etc).

Can we discuss it further?

Best regards,

Kamil Rytarowski
CTO, Moritz Systems
www.moritz.systems

On 13.10.2020 19:05, Luis Machado via Gdb wrote:
> Hi,
> 
> I don't know about other non-x86 architectures, but over the past year
> I've been noticing more and more regressions being introduced,
> unnoticed, for ARM/AArch64. This is not good and causes a lot of pain if
> you have to keep tracking things manually, like we do now.
> 
> The buildbots worked great for this very purpose, but Sergio has moved
> on to other duties (thanks for all the work!) and can't maintain it
> anymore. The builders are still there though, sitting mostly idle.
> We have a beefy ARM/AArch64 builder, which I can maintain for others to
> use.
> 
> We can do better than to declare things OK after a single round of tests
> under x86, which has been the trend unfortunately.
> 
> The subject of better CI has come up multiple times on IRC, with sad
> memories of the gerrit experiment's demise. Now we're left with review
> by e-mail and no broad testing.
> 
> I think we need to discuss better validation pre-commit and possible CI
> solutions for GDB. It is pretty easy to exercise x86, but it doesn't
> sound fair to other architectures to have to keep cleaning up after
> things that have only been validated on that architecture.
> 
> It would be great to establish a roadmap so we can get GDB's testing to
> today's standards, and maybe revisit the use of more modern patch review
> tools while at it.
> 
> What do you think?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/gdb/attachments/20201014/c47a1185/attachment.sig>