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

[Sebastian Huber]

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

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

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/