Chris Johns commented on a discussion: https://gitlab.rtems.org/rtems/tools/rtems-source-builder/-/issues/93#note_119835 My concern is not about a tool chain bump but the specific case of a change of the major version for gcc, binutils and gdb. I have not seen major issues with changes within a major release. GDB is about host coverage because of its dependence on Python and the problems it brings on various hosts. The other factor is monitoring the packages these tools depend on. Hosts such as MacOS, Windows and to some extent FreeBSD can see problem Linux does not. Often this is a case of Linux distros already installing the needed packages so it hard to see there is a change. For a major number change we need coverage in 2 directions and this does not imply we need full coverage across the combined matrix. The horizontal direction has three pieces, the first is architectures, second BSPs and third is hosts. The vertical direction is the vertical software stack we have as defined by RSB buildsets, for example networking code. As I said before building all BSPs for all acrhs as vertical stack is to big a task. Lets not go there. We have good coverage of the horizontal plane. A vertical stack build will build an architecture and a BSP within that architecture on a host so you could consider a smoke test as a nominated vertical stack build. I also not believe we need 100% clear results in all cases. We should understand the issues that exist for a major release change and then leave scope for discretion on how to proceed. I suspect this will depend on the scale of the breakage and what is needed to fix things. At this point in time I have not considered test coverage as a factor in the procedure? -- View it on GitLab: https://gitlab.rtems.org/rtems/tools/rtems-source-builder/-/issues/93#note_119835 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
