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

[Chris Johns]

On 12/4/21 6:15 pm, Sebastian Huber wrote:
> Hello Chris,
> 
> On 12/04/2021 01:34, Chris Johns wrote:
>> 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 changed the RTEMS 6 tools to track the release branches of Binutils, GCC, and
> GDB. Does this mean a release branch of GDB is broken on MinGW? Is this bug
> reported upstream?

Yes, the link is in this ticket ... https://devel.rtems.org/ticket/4363

I think master is OK but I have not been able to spend any more time on this.

>> 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.
> 
> This sounds good.

Great. I will move this forward to an eng manual update.

> I would address this issue with a continuous integration
> system. I think we have here a similar problem we have with the RTEMS patch
> review. There are a number of quality checks which need to happen before a
> change is reviewed/integrated. Our current approach are post commit scripts
> which I think needs to change.

How do we have CI handle a proposed change?

I know Joel and Alex are working hard to get email logs from MSYS2 for test
results and I hope this extends to the RSB on Windows.

>> Rational
>>
>> [...]
>>
>> 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.
> 
> [...]
> 
> For an RTEMS release it may make sense to use release versions of the tools.
> However, for the development branch I don't see a benefit in using releases. We
> clearly state which tool version is used. It is easy to report bugs for release
> branches of the tools. I reported a couple of bugs which showed up due to the
> regular updates. It definitely helps if you report bugs early (for example by
> just relying to a patch review done last week) and not after several months.
The release is done by branching master so I am not sure when and how we change
to released versions of the tools. If we change to released versions on a
release branch are we throwing away all the testing we have done up to that point?

Chris