<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2024 at 6:43 AM Peter Dufault <<a href="mailto:dufault@hda.com">dufault@hda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee <<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>> wrote:<br>
> On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
> <br>
> <br>
> On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> ----- Am 21. Apr 2024 um 3:00 schrieb Chris Johns <a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>:<br>
> <br>
> > Hi,<br>
> > <br>
> > There has been some discussion about when we will branch and it is timely we<br>
> > discuss this. This is my input. :)<br>
> > <br>
> > While I create the releases I am not solely responsible for milestone dates or<br>
> > thresholds for a release.<br>
> > <br>
> > Please test the RC snaphots on our ftp server. Saying you have is as important<br>
> > as reporting issues.<br>
> > <br>
> > 1. Are all the things need for the release resolved? Tickets reviewed?<br>
> <br>
> 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.<br>
> <br>
> There should be time to get it in. The Gitlab transition needs to be complete before the branch is cut. <br>
> <br>
> > <br>
> > 2. The tickets are now in GitLab and locked down in Trac so how does that work<br>
> > if we make a release now? I do not think it does.<br>
> > <br>
> > 3. GitLab is going to happen soon so do we take this moment in time and make 6<br>
> > with GitLab and learn what we need to do easing dot releases that always follow?<br>
> > If we do not we may end up with 6.1 and then 6.2 that has differences.<br>
> <br>
> We should definitely wait with the release after the Gitlab migration is done and some basic CI is running.<br>
> <br>
> I don't think holding a release for CI is needed. We have the same basic quality and testing we have now.<br>
> <br>
> Requiring more work and improvements just moves the release bar. <br>
> <br>
> 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.<br>
> <br>
> > <br>
> > 4. GitLab breaks the release scripts for the release notes (ChangeLog). Amar and<br>
> > I have discussed a few options but we are yet to test and settle on anything. As<br>
> > is the case with these things easy is often is a series of small things that<br>
> > take time to get right.<br>
> > <br>
> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they updated<br>
> > for a separated legacy network stack, net services and waf building?<br>
> <br>
> Ryan and Ray worked on the autoconf to waf documentation changes a couple of years ago.<br>
> <br>
> I have no idea what impact the separated Network stacks have on the documentation.<br>
> <br>
> The legacy networking docs are separated now with instructions on how to build them using waf:<br>
> <a href="https://docs.rtems.org/branches/master/legacy-networking/index.html" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/legacy-networking/index.html</a><br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
Is that a bug?  Should I figure out what the problem was and report it?<br></blockquote><div><br></div><div>That use case definitely wasn't considered for rtems-lwip and I don't know that it's ever been discussed. If that were intended, I'd expect a "./waf uninstall" target to exist that would remove the installed network stack so that you could install a different one since the different stacks install vastly different sets of headers. IIRC, Chris advocates for installing the network libraries into a different location than the installed BSP to allow you to choose which you want at a later time.</div><div><br></div><div>Kinsey<br></div></div></div>