That would roughly double the load on the development team, as the kernel version is different than that of the current release branch (and will diverge even further in a couple months as the project shifts to 4.19, and the wireless starts using the 5.x framework). I don't know that it could even be trimmed to ar71xx, because you'll have the Lanitq people saying "Why them and not us?"
Yes. 4.4 has an expected EOL of February 2022. Would this do anything but "kick the can down the road" a couple years?
No matter what comes of this thread, people need to realize that their hardware needs replacement soon and that it's "on life support" already, even if they just bought it.
Looking at effective use of limited resources across the range of devices, more than a development branch and a single release branch doesn't make much sense to me.
At least in my opinion, dropping the "tiny" target, which is a configuration change, not a code change also makes sense. Builds for a "normal" OpenWrt failing then become a bellwether for that device, rather than the security blanket of "It was fine on Chaos Calmer, 17.01, and 18.06, so I'll be good for another three releases." I think the "tiny" target had its transitional moment, but now it is a cost, not a benefit to the project overall. Somebody has to identify that the target is not viable, then switch it over to the tiny target, or drop it entirely. While some failures show up on the builders, many times it is not until a user flashes an image. Then there are the scores, if not hundreds of devices on a target that "nobody" tests because they're rare in the community of users who use OpenWrt and would report issues.
So, assuming that the position of the project is something along the lines of, for architecture/target X:
- There is a single branch for a given architecture
- There is a single configuration built for that architecture
Then any device that is supported by that architecture has the basis for anyone to choose how they want to compromise should the default build not be functional, at any reasonable time in the future.
For personal use, that should be sufficient.
For shared use, be it for free or otherwise, some assistance from the OpenWrt build system in meeting all the licenses' requirements would be helpful. You're "distributing" the firmware as soon as you post a link or give it to someone else.
There's not only GPL and the "corresponding source", but many other licenses. Virtually all the different licenses require distribution of something with the binary.
Did you know that your Android phone has in its ROM a copy of every license from every package, along with the differing copyright statements in each? Router manufacturers do the same thing, consuming 156 kB, gzip-ed, on a device I'm working with right now. Now that approach will kill a 4 MB device, so it could/should be distributed with the firmware, rather than in the firmware at the option of the builder.
So, adding to the above two bullets:
- OpenWrt build system be able to identify every license and other required files or content in both the base system and packages
- The build system automatically assemble this content into a single file and compress it as a normal part of the build process
- The build system further assist the user in meeting the requirements for legal distribution of the resulting firmware by, at the option of the user running the build
- Include the resulting "license bundle" in the firmware itself and/or
- Include the license bundle than the ROM image in a single archive
- Include a user-defined statement, such as how the recipient of the firmware can obtain the corresponding source in either or both of the above
(Yes, even if you give away your firmware, or just post a link, you're "distributing" it.)