RTEMS 6 branching

[Kinsey Moore]

On Wed, Apr 24, 2024 at 6:43 AM Peter Dufault <dufault at hda.com> wrote:

> > On Apr 23, 2024, at 5:45 PM, Vijay Kumar Banerjee <vijay at rtems.org>
> wrote:
> > On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
> > ----- Am 21. Apr 2024 um 3:00 schrieb Chris Johns chrisj at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240424/bc91b451/attachment.htm>