On 10/4/21 1:19 am, Joel Sherrill wrote: > On Fri, Apr 9, 2021, 9:07 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
