On Wed, Apr 24, 2024 at 6:43 AM Peter Dufault <dufa...@hda.com> wrote:
> > On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee <vi...@rtems.org> > wrote: > > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill <j...@rtems.org> wrote: > > > > > > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > > ----- Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@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? > 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. Kinsey
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
