RTEMS 6 branching

[Joel Sherrill]

On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> ----- Am 21. Apr 2024 um 3:00 schrieb Chris Johns chrisj at rtems.org:
>
> > Hi,
> >
> > There has been some discussion about when we will branch and it is
> timely we
> > discuss this. This is my input. :)
> >
> > While I create the releases I am not solely responsible for milestone
> dates or
> > thresholds for a release.
> >
> > Please test the RC snaphots on our ftp server. Saying you have is as
> important
> > as reporting issues.
> >
> > 1. Are all the things need for the release resolved? Tickets reviewed?
>
> It would be nice to have the interrupt get/set priority API in RTEMS 6.
> The Cortex-M floating point issue is not yet fixed in the RTEMS master.
>

There should be time to get it in. The Gitlab transition needs to be
complete before the branch is cut.

>
> >
> > 2. The tickets are now in GitLab and locked down in Trac so how does
> that work
> > if we make a release now? I do not think it does.
> >
> > 3. GitLab is going to happen soon so do we take this moment in time and
> make 6
> > with GitLab and learn what we need to do easing dot releases that always
> follow?
> > If we do not we may end up with 6.1 and then 6.2 that has differences.
>
> We should definitely wait with the release after the Gitlab migration is
> done and some basic CI is running.
>

I don't think holding a release for CI is needed. We have the same basic
quality and testing we have now.

Requiring more work and improvements just moves the release bar.

That said, we do need to get some CI processes in place. Hopefully between
6.1 and 6.2, we will have at least one or two BSPs required to build.

>
> >
> > 4. GitLab breaks the release scripts for the release notes (ChangeLog).
> Amar and
> > I have discussed a few options but we are yet to test and settle on
> anything. As
> > is the case with these things easy is often is a series of small things
> that
> > take time to get right.
> >
> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they
> updated
> > for a separated legacy network stack, net services and waf building?
>

Ryan and Ray worked on the autoconf to waf documentation changes a couple
of years ago.

I have no idea what impact the separated Network stacks have on the
documentation.

> 6. I have a few small patches to push and then an update to the RSB to
> pick
> > those changes up before I can create RC4.
>
> I recently checked in a fix for powerpc and the AArch64 multilib changes
> for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be
> updated. Maybe we should even wait for the GCC 13.3 release.
>

I asked about a gcc 13.3 release and we should not wait. They intend to do
a 14 release before returning to 13.3. We should plan to do 6.1 with a GCC
13 branch hash and probably plan to swap that out with a 13.3 tarball when
it's released.

We are good at imposing more requirements. :)




> >
> >
> > Thanks
> > Chris
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> --
> embedded brains GmbH & Co. KG
> 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/
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240423/df2a278c/attachment.htm>