Tool update procedure (was Re: Fwd: GCC 10.3 Released)

[Chris Johns]

On 10/4/21 1:19 am, Joel Sherrill wrote:
> On Fri, Apr 9, 2021, 9:07 AM Sebastian Huber <sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
> 
>     On 08/04/2021 14:50, Joel Sherrill wrote:
> 
>     > Is it time to bump the RSB GCC version for rtems6?
>     I am not sure, we are always quite up to date since we track the GCC 10
>     release branch. I have a test build running with updates.
> 
> I forgot we were tracking the branch not release points. 
> 
> My test build sweeps on centos, FreeBSD, and Ubuntu will kick in later today.
> They run at 445pm Central time every Friday.
> 
> I did manage to build PowerPC and SPARC on Cygwin this week but something
> happens in the rsb on mingw64. I think that is known.
> 
> I want to eventually automate doing a build sweeps on Cygwin and Mingw but have
> to.solve it sending reports to build@ and something like Cron.
>
I would to discuss the how we maintain the tools. The currently broken gdb on
MSYS2 MinGW is a current source of frustration for me and a potential GSoC
student. I have wasted hours on it and there is now a backlog of things
appearing we cannot test on Windows because the tools cannot be built.

I would like to formalise the tool updates procedure for the master branch, ie
currently rtems 6.

1. The master branch of the RSB needs to be able to build the tools for all the
platforms we support. We support Linux (which distros?), FreeBSD, MacOS and
Windows MSYS2.

2. The master branch of the RSB tools need to be able to build tier 1 BSPs.

3. Upstream tool releases are to be used over git hashes unless there is a
specific fix that makes this difficult. A git hash is to revert to a release
once the reason for the git hash being used has been resolved and released
upstream. Newlib is exempt from this because of the close integration with
rtems.git.

4. Tools need to build on the selected host for an update to proceed. Cross
building is a viable solution but that should be considered a deployment
technique individuals can decide to use and not a successful host build.

Rational

1. We need to be able to make releases with as little overhead as possible. I
have invested a considerable amount of time improving the release process
however a reoccurring problem is finding tools do not build on host platforms
core developers like myself do no use on a regular basis. Having the tools build
on all supported platforms spreads this work load out and lets us know and
understand issues well before we need to make a release. Placing the burden on
the person releasing only results in no one wanting to manage a release and
RTEMS again not providing timely releases.

We need to find a balance between updating and working builds on hosts. If a
host does not build and the problem is known about and being worked on then this
should not block an update however we need a means to know when the problem has
been resolved and we can make a further update. The key point is removing the
surprise a release manager gets when things are being built by anyone. If we
know our releases can be managed as a team and not a panic of platform specific
fixes.

2. This item is just being sensible. We need a certain level of confidence an
update is not regressing some targets while improving others.

3. Tracking the state of what we release and provide on master is hard when git
hashes are being used. The upstream tools provide detailed release notes for
releases and not using releases means we do not have access to them, nor do our
users. It is hard to engage with a project when reporting an issues against a
random commit git in their repo. Releases are the established mechanism and I
feel directly using a git commit adds a burden to our project we do not need.

The Next Release and Bleeding Edge

The think future releases such as 7 can be more relaxed but our next release
means the 7 tools become master and subject to these requirements. It is a
difficult line to run between keeping current with tools like gcc and being able
to move that state to master. I feel we will need to consider how this happens
when we next release so we find a process that is sensible and workable. I do
not have any suggestions here at the moment.

Thanks
Chris