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. > > > 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@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> >> -- >> embedded brains GmbH & Co. KG >> Herr Sebastian HUBER >> Dornierstr. 4 >> 82178 Puchheim >> Germany >> email: sebastian.hu...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
