Requests Patches to be Applied to 4.10

[Chris Johns]

On 12/2/21 6:52 am, Joel Sherrill wrote:
> 
> 
> On Thu, Feb 11, 2021 at 1:47 PM Gedare Bloom <gedare at rtems.org
> <mailto:gedare at rtems.org>> wrote:
> 
>     Hi Joel,
> 
>     On Thu, Feb 11, 2021 at 12:30 PM Joel Sherrill <joel at rtems.org
>     <mailto:joel at rtems.org>> wrote:
>     >
>     > Hi
>     >
>     > Phillip Smith pinged me at the FSW via Slack about this set of patches he
>     proposed be added to the 4.10 branch.
>     >
>     > https://lists.rtems.org/pipermail/devel/2019-April/025610.html
>     <https://lists.rtems.org/pipermail/devel/2019-April/025610.html>
>     >
>     > I assume this matches what their project requires. Given that 4.10 is the
>     last unirprocessor version and we appear to be recommending 5 over 4.11, I
>     suggest we consider applying the patches and discuss the possibility of
>     another release. [1]
>     >
>     > I've previously suggested treating 4.10 as a long-term version since it is
>     the last uniprocessor version and a good baseline for behavior, performance,
>     and size.
>     >
>     I've agreed with that view, and in fact we do have several (20+?)
>     patches that have been pushed on top of 4.10.2 (including some that
>     broke internal APIs such as my PIP improvements). So, these patches
>     can be considered for sure for a 4.10.3 cut. But we need to marshal
>     time and resources to make it happen. I'm willing to contribute as I
>     am able to do so.
> 
> 
> I'm thinking initially just evaluate the patches Phillip's project used and
> if they backport cleanly. If they don't, perhaps just file a ticket. If they are
> low hanging, just push them. And run tests on say leon3 and psim.

All the patches listed in the link would need to be reviewed and tested so there
would need to be some sort of test plan. The 4.10 branch has sort of switched to
the RBS and release scripts. See the 4.10.3-rc2 package on ftp.rtems.org.

>     > [1] Yes I know release cutting is thankless unpaid work. First step is
>     just applying patches.
> 
>     If I remember the discussion right, we came to the conclusion that
>     maintaining 4.10 would require more resources than we have available
>     to commit. I would suggest we identify what the costs may be
>     (hardware, labor) for a long-term stable 4.10 version, and target some
>     fundraising toward users that would benefit from it. I guess there may
>     be at least some space and EPICS users that might be interested.

Yes this is my understanding. I am reluctant to move away from this plan and
make an exception. I have 4.11 in production in a number of systems and a 4.11
release is also needed.

> Cutting a release does involve thankless work and fixing a patch which
> doesn't backport very cleanly is also engineering.
> 
> I'm not disagreeing particularly on any point. We have finite resources 
> and funding core developers is the way to make something a priority.
> I can definitively state that a user's sponsorship of a code developer 
> got the 5 series over the hump and 5.1 out the door. It was greatly
> appreciated. 

Yes it was and I thank you for raising 5 because it is important we convey to
our users they can make a difference in these areas. It is great that Philip has
raised this but time only makes the problem harder.

A 4.10 release needs to deal with all hosts and all architectures and this makes
it complex given the host OSs have changed. To cut a 4.10.3 release I would need
to update the RSB to include a lot of recent changes to handle the python
version mix and then the built tools would need to be checked against the 4.10.2
build. I am not sure this happened. All of this takes many hours.

Chris