<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 11, 2021 at 1:47 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Joel,<br>
<br>
On Thu, Feb 11, 2021 at 12:30 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
> Hi<br>
><br>
> Phillip Smith pinged me at the FSW via Slack about this set of patches he proposed be added to the 4.10 branch.<br>
><br>
> <a href="https://lists.rtems.org/pipermail/devel/2019-April/025610.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-April/025610.html</a><br>
><br>
> 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]<br>
><br>
> 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.<br>
><br>
I've agreed with that view, and in fact we do have several (20+?)<br>
patches that have been pushed on top of 4.10.2 (including some that<br>
broke internal APIs such as my PIP improvements). So, these patches<br>
can be considered for sure for a 4.10.3 cut. But we need to marshal<br>
time and resources to make it happen. I'm willing to contribute as I<br>
am able to do so.<br></blockquote><div><br></div><div>I'm thinking initially just evaluate the patches Phillip's project used and</div><div>if they backport cleanly. If they don't, perhaps just file a ticket. If they are</div><div>low hanging, just push them. And run tests on say leon3 and psim.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> [1] Yes I know release cutting is thankless unpaid work. First step is just applying patches.<br>
<br>
If I remember the discussion right, we came to the conclusion that<br>
maintaining 4.10 would require more resources than we have available<br>
to commit. I would suggest we identify what the costs may be<br>
(hardware, labor) for a long-term stable 4.10 version, and target some<br>
fundraising toward users that would benefit from it. I guess there may<br>
be at least some space and EPICS users that might be interested.<br></blockquote><div><br></div><div>Cutting a release does involve thankless work and fixing a patch which</div><div>doesn't backport very cleanly is also engineering.</div><div><br></div><div>I'm not disagreeing particularly on any point. We have finite resources </div><div>and funding core developers is the way to make something a priority.</div><div>I can definitively state that a user's sponsorship of a code developer </div><div>got the 5 series over the hump and 5.1 out the door. It was greatly</div><div>appreciated. </div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
> Thoughts?<br>
><br>
> --joel<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>