On Thu, Feb 11, 2021 at 1:47 PM Gedare Bloom <ged...@rtems.org> wrote:
> Hi Joel, > > On Thu, Feb 11, 2021 at 12:30 PM Joel Sherrill <j...@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 > > > > 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. > > > [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. > 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. --joel > > > > > Thoughts? > > > > --joel > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel