> 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? > > > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
