I have seen in the forums and also testing myself the many people are running LEDE 17.01 pretty stable and with good performance on older devices (32MB of RAM and 8MB of Flash). As we know there are 18.06 builds for many of these devices as well but that were reports of slowdowns, instability, higher latency or cases that was necessary to downgrade. On some discussions people mentioned that this may be due to two main things: a) newer kernel footprint b) newer LuCI of 18.06.
Even for some devices with 32MB of RAM and 8MB of flash it was noticeable that 18.06 wasn't as stable as LEDE 17.01. There are also successful tiny and stable builds for devices with 32MB of RAM and 4MB of flash and which would be even harder if not impossible to keep the bare minimal due to the bigger footprint of 18.06 for these cases. I fully agree 4MB of flash is out of question for 18.06 and going forward but there are several success cases for 17.01 tiny and custom builds. Note that as just mentioned there are cases where even with 8MB of flash 18.06 version has not been an option so the question here isn't really the size of flash but the impossibility of running 18.06 stably.
We know that OpenWrt has been responsible for given a lot of extra life to routers due to its newest features. Just to mention one great example: full IPv6 support to routers where manufacturers stopped to develop firmware upgrades.
Given that the point I want to put is to perhaps extend 17.01's life and support beyond January 2019, at least to receive security patches.
I would normally agree with its retirement as normal part of OpenWrt life-cycle but I fell that in this case we have a kind of special situation where it is worth to keep it alive for a little while until there is a lot of these very usable hardware around.
Again, someone has to do it. Being open source you're free to fork OpenWrt and maintain it. This has been discussed as a part of the 4Mbyte flash devices retirement (use search).
If the size of packages such as LuCI vs. RAM is the issue, why not sacrifice non-crucial packages when you would like to continue using such old devices? I would prefer current and maintained packages with less features over old unmaintained software anytime.
Sure, LuCI is convenient. But how often do you really need to change your router/access point configuration? I have stopped using the web interface quite a while ago even though my device has plenty of flash and RAM to accomodate it. I use my OpenWrt device as an access point, and the last time I had to change it's configuration was already months ago. I can just do that over SSH.
If you really need a lot of packages and don't want to buy a new full-fledged router, there's also the possibility to buy a cheap ARM SoC and let that handle some of the work or services.
@diizzy that's not the point. We are talking about the project overall direction. That doesn't depend on a single person wishes so why I am putting for discussion to see everybody's point of view.
@silentcreek the main point is about not being able to run 18.06 in these routers at all regardless the flash size. Not using LuCI unfortunately isn't the case for the vast majority of people so that's out of question looking form a practical point of view for most people.
The main objective is to give extra life and support to these good old hardware which are still usable and the proposal is not for that to be undefined, but just a little over the usual given this particular scenario.
And as mentioned to minimize workload the proposal is not to have new features or backports, but only minimal security and essential fixes.
Because the issue is that you can barely (if it's even possible) fit the kernel and bare minimum userland libraries and applications. In the end it's of little interest to maintain lots of size hacks and even if you would 32mbyte of memory would still be an issue with recent kernels and software. Apart from that someone needs to do the work and here's where funding and interest (developers and contributors) comes into play. It needs to be a group effort and that group doesn't really exist right now.
It's not so much a matter of justification as it is a matter of mechanics; i.e. writing the code to maintain the branch. The economics are that developer time, talent and resources are scarce and can be applied in other areas which have more potential to move the project toward more of its stated goals.
There is more to it than just backporting security fixes. Developers tend to focus on the packages they use on the platforms they use and the branches they are running (which tend to be newer branches). If you want security support, you need developers interested in such an old branch and the devices. Because if you provide fixes, you should also be able to test them. And providing such fixes also means to keep an eye on those old versions and packages to determine whether a new fix needs to be backported which is already an effort even if the result of that effort is the finding that the version is not affected.
In addition, the current state of security support for packages varies heavily. You could problably consider quite a few packages as orphaned. So while providing kernel fixes is possible as long as they are provided upstream, it's not as simple for the vast amount of packages (some are not supported upstream anymore, such as samba for example). Even if there is someone willing to provide supoort for the kernel and maybe a few base packages, I think this would give people a false sense of security when the kernel is updated but some of their installed packages have not seen fixes for months or even years.