Planning for RTEMS 6 Branch

[Joel Sherrill]

Hi

It took a long time to get from 4.10 to 4.11 and then on to 5. I don't see
any reason getting from 5 to 6 should be such a long period of time. It
seems as if we focus on a few major changes and see what happens while
those go in. Right now, I'd be prone to say 6 is ready to branch from a
feature perspective if we get the following:

+ Waf switchover complete
+ NFSv4
+ aarch64 on real hardware and SMP

I would expect all of this to be available in early 2021.

There are already new BSPs (stm, etc), tool updates, etc. that are a normal
part of RTEMS moving forward. These don't really play into my thoughts.
They show up when they show up and we can delay branching a very short time
if something is on the cusp. But they don't drive release planning.

In my opinion, the big question is addressing RTEMS for EPICS. Most of the
BSPs I know that are used for EPICS are still only supported by the legacy
stack. I'm ignoring some known BSP regressions that will get fixed as a
normal part of moving forward. If RTEMS 5 + EPICS uses the legacy stack,
that's OK. But I'd like to move the legacy stack to its own repository.
Downgrading the legacy stack that way while BSPs used by EPICS users
haven't been updated to libbsd is not a good thing. I expect
motorola_powerpc and beatnik/mvme5500 to be on libbsd sometime in the near
future but that leaves other EPICS BSPs. We need to include EPICS
considerations in our roadmap. This means the legacy stack can't be moved
out without considering them. And we need to figure out how to bring them
up to date. This needs to be part of release planning.

The other big work is the qualification effort. It would be nice for it to
be complete but I don't see that as a blocker for RTEMS 6. It could be the
driving factor for RTEMS 7 if the timeline doesn't work out.

Basically, I'd like a quicker RTEMS 6 even if 7 comes out quickly to
address the legacy stack. Each of these still has major user facing
considerations. Let's just be quicker.

Thoughts?

--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201216/a1ad2d22/attachment.html>