RTEMS 6 branching

[Peter Dufault]

> On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee <vijay at rtems.org> wrote:
> 
> 
> 
> On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill <joel at rtems.org> wrote:
> 
> 
> 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.
> 
> The legacy networking docs are separated now with instructions on how to build them using waf:
> https://docs.rtems.org/branches/master/legacy-networking/index.html
> 
> We might need to mention in the user manual that there is no default networking stack anymore and the user needs to build the network stack separately.

I do (or did, haven't checked lately) have an issue that if I "./waf install" one of the network stacks, probably "libbsd", that I can't then switch back and forth.  I think a header file got installed that broke things.  Don't know if that was fixed, I've just been careful to not install either stack so I can switch.

Is that a bug?  Should I figure out what the problem was and report it?

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


Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering