<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Am 21. Apr 2024 um 3:00 schrieb Chris Johns <a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There should be time to get it in. The Gitlab transition needs to be complete before the branch is cut. </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I don't think holding a release for CI is needed. We have the same basic quality and testing we have now.</div><div dir="auto"><br></div><div dir="auto">Requiring more work and improvements just moves the release bar. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Ryan and Ray worked on the autoconf to waf documentation changes a couple of years ago.</div><div dir="auto"><br></div><div dir="auto">I have no idea what impact the separated Network stacks have on the documentation.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 6. I have a few small patches to push and then an update to the RSB to pick<br>
> those changes up before I can create RC4.<br>
<br>
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.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">We are good at imposing more requirements. :)</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
> <br>
> Thanks<br>
> Chris<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
<br>
-- <br>
embedded brains GmbH & Co. KG<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>