Support and updates on Openwrt

What are the "official" Openwrt's supported versions?
It looks like LEDE (v17) still is but what about the rest?

When you login in Ubuntu you usually get some stats on packages that have updates available and security updates pending that can be easily updated with apt. If you have a GUI, you also get some similar notifications and options to updated with a click. Why Openwrt does not have something similar?

Is there a clear timeline for how long current and older version will be supported?
I think that having a clear planned support plan with LTS versions like Ubuntu would help Openwrt's users and clarify expectations among core dev and users.

http://lists.infradead.org/pipermail/openwrt-devel/2018-November/014526.html

17.01.x will only be maintained until january/ february 2019, so now is the time to plan the upgrade to 18.06.x or the upcoming 19.01.x.

18.06.x is obviously still maintained, until the next major release after 19.01.x.

15.05.x hasn't been maintained for at least two years, effectively probably longer; no need to even discuss earlier releases, for those you'd really need to look into the history books instead.

Thanks. It would not be a bad idea if these info could be on a pretty visible page on https://openwrt.org/

@slh, in that @hauke 's message that you linked I read:

The following targets currently use kernel 4.9 and should be upgraded to
kernel 4.14 if they should be in the next release:

  • ar7
  • ixp4xx
  • layerscape
    Someone from NXP said they will provide some patches in November.
  • brcm2708
    I looked at the kernel patches from here:
    https://github.com/raspberrypi/linux
  • at91
    Someone from Microchip already proposed some patches
  • orion
  • rb532

My question is WHY?

It seems there is a rush to upgrade the Linux kernel too soon. Since Openwrt can already support multiple versions of the Linux kernel, what is the motivation? Would not sticking to the LTS versions of the kernel and their timelines for support be better?

Routers are usually shipped by the manufactured with a specific version of the kernel and they do not upgrade it. When you try to run that device with an updated kernel, the device stops working well (there are some good exceptions to this). I think everybody prefers a working performant stable router compared to run with the newest kernel and having a slower and unstable device. For some devices, some problems will never be fixed for lack of time and people's effort on that specific device. Sometimes the new kernel does not fit the RAM or Flash so the device support needs to be dropped. Who wants that?

In this specific instance, according to https://www.kernel.org/category/releases.html the 4.9 kernel will be supported until Jan 2023. While the Kernel 4.14 until Jan 2020.

Among what I can read here: https://kernelnewbies.org/Linux_4.14 I do not see anything that as a router owner would make me scream "I need to have it!"

Correct me if I am wrong. So far I see:

Cons of upgrading

  • 3 year shorter Kernel support.
  • Those targets will have to be move to the next version by 2020 that means more work, more hardware requirements, more devices that will have to be dropped in 2020.
  • Most of the devices using that new kernel will be slower at best.
  • Dropping support for a bunch of devices because of memory constraints.
  • More work to fix what is currently working.
  • More users that in order to keep using their devices will run an unsupported version of Openwrt and will be exposed to the risks of unpatched security vulnerabilities.

Pros of upgrading

  • Being able to say: "We are running on a newer version of the kernel"
  • Anything else?

I know that people always want the latest and the greatest. I think because of the perception of being "updated" is associate with more secure, faster, more feature, "better" in general. But as far as I know, this is a wrong assumption and it is rarely the case here.

v4.9 seems a very nice sweet Kernel version to stick too.

Disclaimer: I'm not an OpenWrt developer, I'm not involved in the decision making process in any way, shape or form.

Please don't expect a full dissertation here, defending the positions stated in that roadmap.

The short version would be, because the OpenWrt developers consider that to be the way forward - and the opinion of those who end up having to do the work (and who have the experience gained from previous releases) is what matters.

Just to explain some of the points you raised.

Each additional kernel version to support concurrently multiplies the maintenance efforts, think about out-of-tree kernel modules (wlan stack, wlan drivers, wireguard, down to simple userspace packages with dependencies on kernel features or modules)

4.9, 4.14 and 4.19 are LTS kernels.

The kernel is one component which is slowly getting larger, but by far not the only one - where do you draw the line, how much effort can you spend to keep track of these.

Users may also want to connect their new LTE or 5g USB device (or more basic, e.g. any USB 3.x device), which only got supported in a newer kernel - yes, often they even want to connect those to older devices (e.g. there's no reason not to attach such a device to a ar71xx/ ath79 based router, many of which are ressource constrained). Another very regular source for upgrade requirements are new hardware revisions of established devices suddenly shipping with different/ newer flash chips, requiring updates for the mtd subsystem. Another topic are new kernel features, like e.g. I³C, nftables or bpf support - or just SQM, which has just been merged mainline recently.

That remains to be seen, 2020 is only the expiration date 'guaranteed' for at the moment, but the dates for 3.18, 4.4 or 4.9 have all been extended afterwards (and 4.14 is the base for an android kernel, look at distributions like RHEL, SuSE or Debian who have adopted stable kernel maintenance in the past). Furthermore this isn't really relevant here, considering that 18.06 has a planned EoL date around summer to fall 2019 (with 19.01 probably ceasing maintenance in early 2020), if you'd have read the previously mentioned roadmap.

It is up for a debate what is an easier maintenance concept, doing smaller steps more often - or huge steps if you can't avoid them anymore (because there is no LTS coverage anymore). What is less open for debate, is the question of testing, as long as a SOC hasn't actually been ported to a newer kernel, no one knows what might have broken in the mean time (and this also implies testing by real users, maintainers don't have all hardware and won't test everyting). The larger your steps between kernels, the shorter your notification time of when space (flash, RAM, CPU performance) runs out - or the time to find out how to counter these.

This is questionable for devices above the cut-off (8 MB flash && 64 MB RAM), but what you fail to notice is that there'll also be new devices coming to the market, which can only be supported by kernels newer than 4.14; users and developers also have an expectation towards getting those working. This will apply to basically all 802.11ax/ "wifi6" platforms, which are slowly entering the market.

…and we're back to https://openwrt.org/supported_devices/432_warning - yes, at some point devices will fall off the cliff (you may extend that time by stripping off features that are deemed part of a default image). You can't run windows 10 on your 75 MHz Pentium 1 based computer with 64 MB RAM either, although it ran comfortably with Windows 95.

…and less work to support upcoming devices, e.g. the -currently mind blowing- number of external patches required to support the various RPi like devices will be seriously reduced from kernel 4.19 upwards, which has much better mainline support for brcm2708 (brcm283x). The same goes for the sunxi target (Allwinner ARMv7/ ARMv8 boards), which has very active mainline support. Furthermore there is active development for mainline on (at least) brcm53xx/ brcm63xx, lantiq, mt7621 - and now also for the device tree based ath79 target (replacing ar71xx), developments that slowly help to reduce the delta to the mainline kernel and thereby reduce the workload for OpenWrt. Yes, in many cases these mainlining efforts are driven by developers also involved in OpenWrt, but not exclusively - and for those developers it is important to stay relatively close to current'ish mainline.
Additionally there are upcoming targets already asked for, which will require at least kernel >= 4.17 - or users running OpenWrt on x86, including very current chipsets, that's before even looking at the topic of driver support for addon devices users might want to attach (USB, SDIO, SPI, I²C et al).

The more you diverge from the (current!) mainline kernel, the more work you'll have to do yourself - and the less you can rely on support from upstream kernel developers (e.g. there was a bug with NAND based devices recently, whose debugging had been significantly hindered by there not being any intermediate steps between 4.9 and 4.14 - and 4.14 being too far from the current code (v4.19/ linux-next) to get effective help from upstream). The target for OpenWrt is to reduce the delta to upstream, to reduce the amount of changes that have to be maintained in isolation by OpenWrt developers, both to make integrating newer targets (for new devices users really care about) easier and to allow interacting with (mainline) upstream.

2 Likes

Very helpful explanation. Thanks.

Sure. I just wonder what are Openwrt's values on what these choices are made. I haven't been around the community long enough but I have been in threads where support for a device is denied for reasons that do not make a lot of sense to me. Ex: This post and you can look at latest discussions

In the past I though that considering how many devices became unsupported from version to version, only one kernel version was being supported for simplicity. I was happy to find out it is not the case. I understand the complexity to be able to compile some shared code for hundred of devices. At the same time, I wonder if it would be possible to reorganize the repo to be able tto minimize the changes for device as new updates come out.

Being able to update Openwrt with the latest security updates in a way that I do not have to go track down the single updates that need to be applied seems a pretty important feature. If you think about the main Linux distributions like Ubuntu they are able to support a lot more hardware than Openwrt and at the same time they keep supporting the LTS versions for a few years.

How does Ubuntu do it?

I am not saying: no progress. People on newer kernel may be more aggressive. I am saying that once they decide not to invest a lot time on certain devices, they should be still supported in a minimal way that guarantee security patches and performance/stability.

What I am saying is that for the average device the support to the latest version of Openwrt seems pretty short. Considering that major versions updates are introducing big breaking changes that end up resulting in a lot of routers not being supported anymore (or supported with high instability or performance problems), I think there should be a strategy to at least provides some backward support for devices. As it is right now, even the service releases of the main version are not very frequent.

All the Agile literature demonstrates that small batches guarantee more stability and better resource utilization.
The concept of Just In Time is pretty much "product is shipped" as soon as it is ready.

Update are usually shipped to either fix a bug or add a feature. The feeds are already a huge step in that direction. I just wonder why we cannot publish modules more often maybe adding kernel updates and notify the user that an update is available. If there is a log of the update from version X to version Y, a user could rollback in case they have a problem with module. I actually have a better idea (more below).

I was already thinking about this and I agree with you that testing is a HUGE problem. There is not a easy solution. Since a warehouse of routers with a CI system to deploy and test updates before rolling out to the public does not seem very realistic, I have an idea.

I think there is a need of notifications of updates available. So I assume that one will be there.

I order to guarantee more frequent and stable updates we can transparently tell them what is new and track what the user does.
So when there is an update in a package, the package can be made available on a beta feed. People can choose to subscribe the beta feed (ideally with just a checkbox on LEDE). Everybody may receive a notification it would just say that it is in beta and warn about instability... Once enough users would have confirmed that it works fine, the package can go out of beta and shipped on the regular update channel. If the package is still in beta, we can actually prompt in LEDE or on login on SSH a week after the update asking if everything works fine. You can add all the bells and whistles on top of it: checkbox for autoupdates, moving from "beta" to "stable" by device. You can even blacklisting devices where the upgrade was creating problems. Etc. I would argue that this would also increase participation. For example if a programer that notice that an update on a component that they care about is blacklisted on their router, they may decide to look what the problem is, fix it and submit a patch.

What about adding some changes so that supporting multiple versions of a package (including the kernel) is easy. I am not sure what the current overhead for an extra version of the kernel is. You can add a new kernel for the new devices and still maintain the old one for older devices. I think it is better to have people pushing or doing the work to migrate their device to the new kernel if they really want to, than forcing them to upgrade removing support of a older kernel.

I am sure there is quite a lot of requests coming from people reporting that their device is broken. Unless the default is to ignore them, this will create a significant amount of work. I think there is an unnecessary churn coming from fixing problems related to the upgrade that could free time for the code developers.

Sorry, I heard this before but it sound like a all or nothing logical fallacy. "Because we cannot support 20 years old routers or it does not make sense to support them, then we should not support any old devices" I think Netgear still supporting the R7000 that was released 5 years ago should demonstrate that it is just a matter of deciding what it matters and what you want to do.

Absolutely in agreement here to stay as close as possible to mainline. And you also have to look at the context and the constrains. A device driver that runs on a Linux PC has less memory constraints than a router. The configuration system of Openwrt seems pretty powerful. Why cannot be easy to encode the dependencies on a older kernel?

I would be happy in a system similar to the one used in npm audit. There are other similar tools for other languages. If you can get a report of the current vulnerabilities on your devices, some people will move to fix the problem. The first step is make the situation visible.

Currently people even on newer devices end up running Openwrt for 1 or 2 years on a device until it is supported with not super regular security patches. Most people after the support ends continue to run the device with no patches for a few more years. They eventually sell the device to somebody that keep using for even longer time. sometimes I wonder if relaying on the manufacturer's firmware may be a better option for some devices.

On https://openwrt.org/#why_use_openwrt Security is one of the bullet point. But I fell like that it is quite misleading. The security aspect is the part that was left out in your latest message. I am ok that you do not have something to say about it. But I really think it is the part that needs a better answer from the core devs.

Patches are patches, no matter how much sugar coat and repo restructuring you perform around them. In the end of the day, someone has to forward port all patches to new kernel version, compile test all 40 targets and manually review patch conflicts in case of non trivial rebases. Its tedious, labor intensive work that can eat between a few hours and several days worth of work which is usually not payed for by everyone.

Ubuntu targets mostly targets x86 platforms and a few selected very capable ARM devices. I don't think space constraints are of any consideration for Ubuntu.

We do support devices in a minimal way with security and bug fixes, mainly by cherry picking relevant fixes from the master branch back into the still supported branches. There are autobuilders for each active branch which continuosly generate updated packages. If larger security issues come up (Spectre/Meltdown, KRACK, ...) we put out new maintenance releases with refreshed images.

I think this is about as good as it gets, any demands beyond that are unreasonable and impossible to address given OpenWrt's current personell capabilities. Nobody working on OpenWrt has the time and financial resources to provide support for devices 5, 6, 7 years down the road. It is simply not going to happen.

I disagree. Taking for example the TL-WR1043ND which was first supported in 10.03.1, released december 2010 until at least 17.01.6, released in september 2018. This is almost 8 years free of charge support. not sure what else you expect beyond that.

Where is this completely wrong notion coming from? What are frequent releases?

17.01.0 - Feb 2017
17.01.1 - Apr 2017
17.01.2 - Jun 2017
17.01.3 - Oct 2017
17.01.4 - Oct 2017
17.01.5 - Jul 2018
17.01.6 - Sep 2018
18.06.0 - Jul 2018
18.06.1 - Aug 2018

Not sure if you expect a new release every one or two weeks to be happy, but if this is the case then this is definitely not going to happen, sorry.

If you want to always use the latest tip of the respective branches, use http://downloads.openwrt.org/snapshots/ or http://downloads.openwrt.org/releases/18.06-SNAPSHOT/, http://downloads.openwrt.org/releases/17.06-SNAPSHOT/

As for the notification infrastructure - someone has to implement it, add the necessary changes to OpenWrt, the gui, the builders etc.

So the question here is - who is going to implement that, who is going to do the merging, categorization, greenlighting of packages. Who is going to test them, address bugs etc.? What you demand here is a lot of work the project simply isn't able handle.

Upstream kernel development progresses so fast that this simply isn't feasible in the long term. Having out of tree drivers (mac80211, wireguard, mt76, ...) or even userspace (cake, openvswitch, ...) support widely different kernel versions is a lot of work which often is hindered by the lack of suitable hardware or suitable test cases to even assert the functionality of all the different version combinations. Each further version exponentially increases the effort required to keep stuff working.

Think about it, you demand a level support here which not even the OEMs can provide for their own device designs, and they only have to support a fraction of the environments OpenWrt supports, with full access to sources, schematics, erratas and so on.

Correct - and the 4-5 active OpenWrt base contributors actually doing a majority of the work decided that they cannot handle providing support for all devices accress 40 targets for 5+ years while still developing OpenWrt and backporting latest upstream features into old kernels, merging patches, handling infrastructure and porting OpenWrt to new devices.

If you need that level of support then consider building a downstream distribution based on OpenWrt with support for a selected subset of devices and maintenance for a few years down the road. Maybe even take a stab at e.g. maintaining the 17.01.x branch out of tree and if it works out well, offer to take over the maintenance.

Staying as close as possible to mainline and doing LTS are mutually exclusive requirements imho. Mainline does not care about LTS, mainline does not care about out of tree and mainline does not care about heavily resource constrained systems.

Encoding dependencies on a kernel version is the least part of the work, making sure that entire out of tree subsystems work across different kernel versions with wildly different APIs while simultaniously working on upstreaming them is the hard part. Most developers do not want to handle the load of juggling three to four distinct branches of components at any point in time.

https://sdwalker.github.io/uscan/
https://openwrt.org/releases/18.06/changelog-18.06.0#security_fixes
https://openwrt.org/releases/18.06/changelog-18.06.1#security_fixes
...

See also the recent work on tagging components with CPE IDs to allow for NVD cross referencing etc.

This is nothing OpenWrt can help with, unless you add mechanisms to forcibly disable the firmware after a set amount of time.

Note that security not only comes from updating things all the time but also from providing a somewhat secure default configuration, from reducing the available attack surface, from providing source code access to at least have the theoretical ability to review and patch code and from giving the tools to lock down the system.


To summarize the discussion - lots of things you demand from OpenWrt here would exceed the level of support provided by distributions like Ubuntu or Debian with only a tiny fraction of the funding and developer resources available.

Did you ever wonder why you simply can't insteall Debian or Gentoo on a TL-WR1043ND or a Linksys WRT1900AC? It is because such embedded devices impose constraints on the distribution which render most traditional Desktop world processes unusable while simultaniously require a lot of specialized developer knowledge.

Such specialized knowledge is rare, even more so if its unpaid. And the people that do it for the "fun" of it will only do the things they deem interesting or worthwhile. Tedious grunt work and distribution maintenance will not attract developers, it requires monetary compensation or another motivating factor which I couldn't yet spot in these discussions.

Turning OpenWrt into a full-blown, LTS supported distribution with extensive regression testing and very narrowly focused future development roadmaps will exceed the capabilities of the current contributor base.

Implementing such a distribution requires a lot of professional organization and appropriate incentives which I simply do not see in the immediate future.

4 Likes

@jow Thank you for the answers and references. I am not going to answer point by point this time.
I understand that supporting Openwrt as it is, it is already a lot of work.
It seems that there is a scaling problems and doing more of what has been done in the past, it is not going to help much. When Facebook in 2008 wanted to be quickly localized in different languages for the first time, they decided to build a tool so the users can contribute to translate the app in their own language. Some articles 1 - 2 - 3

So what about providing visibility about the status of the firmware on people's router UI and command line so there is visibility of how good or bad the situation is and provide incentives and suggestions to people on how they can help?

To summarize some of the suggestions on what it can be done in this regard:

  • Make everything as much modular as possible so it can be independently updated. I think Openwrt is already at a good point with the feeds. Maybe something more could be done for the kernel.
  • The updated are indexed and pushed on some free place (a gist on github a repo or whatever). The routers can connect regularly and get the index, do a diff with what it is currently installed and provide feedback to the user. By default this is on, but it may turned off. This can also push something like "The support of your router was terminated on xx/xx/xxxx. Your system cannot be updated and may have security vulnerabilities...." or "The package xxx is vulnerable to xxx (link). An update was developed but it is not compatible with your router. Do you want to help to fix it? Check this link " Just an example.
  • There is one button for pulling and installing all the updates or selectively install some packages.
  • Increase stability and more organized feedback. When there is an update in a package, the package can be made available on a beta feed. People can choose to subscribe the beta feed (ideally with just a checkbox on LEDE or a command on the shell). Everybody receives a notification. It would just say "package xxx installed x.y.z - there is x.y.z+1 in beta. The package may not be stable on your device. Click here to learn more... click here to install. Once enough users would have confirmed that it works fine, the package can go out of beta and shipped on the regular update channel. If the package is still in beta, we can actually prompt in LEDE or on login on SSH a week after the update asking if everything works fine. You can add all the bells and whistles on top of it: checkbox for autoupdates, moving from "beta" to "stable" by device. You can even blacklisting devices where the upgrade was creating problems. Etc.
    This will need a web frontend and a backend API. I am happy to help to architect this and help with development.
  • mine the data to provide clear info to the user about compatibility and instability among packages and configuration in an automated way. It would be easier to provide updated information by device on supported versions instead of cross referencing the wiki with mailing list messages and forum to make sure it is updated.

What do you think?


Regarding supporting beta vs stable and more kernel versions.

In some development environment you have a development branch and a master branch (see https://nvie.com/posts/a-successful-git-branching-model/ ). Feature branches are created for specific features and merged to development after code reviews and CI testing. When there is a release development is merged to master and master is released. As it is I doubt it would work for Openwrt but I wonder if it could bended in some way to get something usable.

I am brainstorming here so be prepared to crazy ideas.... I probably I do not enough understanding of Openwrt across different targets and devices in the same targets but still worth trying. It seems that the key it is to find the best way to put the similar enough code in a cohesive manner in one place but also make sure it is easy to branch when the code is different enough.

What are the cons of the current folder structure? And how could be rearranged differently?

Maybe the folders need a different structure? What if instead of targets, there are specific chips.

What if each device had a beta and stable branch. Definitely there would be a lot of branches but what if you could have some tooling to merge some code in multiple branches (maybe all those in a target, all those with a specific kernel version, etc) with just a command?

Maybe just having a branch for each target?
Maybe there should be a branch for each kernel version instead?

Can somebody add some ideas?

@Camicia

One thing that you seem to gloss over is that compression of the firmware is the only reason that many of the devices you seem to be championing can run any current kernel, core application software, and the kind of GUI that many users seem to demand. As soon as you start upgrading a running system, you end up consuming flash quickly, as you not only have the compressed version in ROM (both per-binary, as well as de-duped), but also an uncompressed version in the flash-based overlay filesystem. Also remember that the flash used in these devices is about the cheapest on the market, as a manufacturer only needs to support tens of write cycles.

These are not impossible problems; but let's say that it is "rather challenging" to be able to download something like 15-30 MB of binaries, assemble them into a image, XZ compress the image, persist the current configuration and binaries needed for upgrade, all in, oh yeah, 16 or 32 MB of memory.

Poor translations do not brick devices. Poor code does. For that matter "decided to build a tool so the users can contribute" is git

Git was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development.[12]

This pretty much sums up how I read your posts @Camicia. You seem to be have heavy opinions on subjects that you don't understand much about. Support for the device (zsun) was not rejected, that specific PR was rejected because it did not comply with guidelines. You are free to rework them until they are suitable. You've been well informed about it but you seem to have ignored the answers.

You have a lot of "ideas" that doesn't make sense at all, that nobody wants and you don't supply any code. I've noticed this kind of attitude more lately. People seem very ungrateful and oblivious to how this free and open source project is run.

@escalade. I am sorry if I gave the impression to be ungrateful. Because I am REALLY grateful to everybody that decide to spend time on open source and donated their time for the benefits of others.

Regarding the ZSUN, the day I wrote this, I did 80% of the PoC of the simple tool that let you add the wireless password on a compiled image of Openwrt. I ended up spending almost a full day on it. Then the following day I asked myself... why do I really care? Who cares?

Now regarding "rejecting", you are probably right that it is not completely accurate term for this situation that is a more complicated...
[NOTE]I started writing the details of the story and now I feel again "Why are you doing this? Why you put so much effort in this?"...[/NOTE]
The patterns that I have seen here are: ignored, told you need to put work into this if you want to be even listen to, told that you should have followed the rules/policy (buried in wiki at best, or in some message in the mailing list other times), go to re do it, told "why you even bothered, what you have done is not right. Go fix it and Maybe, just maybe we will merge it", then ridiculed for wanting to contribute.
I mean... it seems that Openwrt still attracts a bunch of good people from time to time but instead of trying to retain these people in the long term and convert them to long time contributors, they are ignored at best,
or almost bullied at worst.
And then finally I hear complains that something cannot be done because there are not enough people working on Openwrt, people are working for free and they should be paid instead...

If only people were warmly welcomed, if they were able to easily find how to contribute, if their attempts to help were encouraged and supported early on, I think there would be more people helping Openwrt to grow here than people leaving and not looking back.

The only reason I write this is because I still hope that somebody realize what is going on and try to make things better in "people things".

Best, Camicia

Don't think it is about welcome signs.

There are many ways to contribute.

But writing or editing code and then submitting a pull request of your changes is a concrete way to contribute.

But you shouldn't feel un welcome if your submission or idea is not accepted.

Seemed to me like you are trying to bully the OpenWrt devs. What is it you are trying to contribute here then? Stopping them from porting code to new kernels? Do you have a specific example of a device that actually got slower as you say or got issues with updated kernels in stable relases of OpenWrt?

Where did you get ridiculed for wanting to contribute? I am very sorry if this was the perception but from glossing over the posts you made in this forum I couldn't really spot such reactions.

Unfortunately it is very common in the FOSS world that contributions are not accepted as-is or even sometimes completely rejected because there's different views on architecture, code style or implementation details. It is also true that comprehensive contribution documentation would aid to avoid tedious respinning cycles before submitting the code. On the other hand a project cannot simply merge anything just to avoid putting people off and sometimes a contributor has to bug people to get attention and things included.

These are some rather serious accusations you make here. I find it worrisome that the rejection of contributions or the demand for reworking is perceived as bullying.

The complaint was not that people should be paid to work on OpenWrt, the argument was that there's little frequent contributors available to handle additional work.

The ideas presented in this thread require a multiple year commitment to the project and the willingness to invest serious amounts of time, architectural work and coordination of many different components, infrastructure bits, involved people and so on. This is why they tend to trigger a rather negative reply.

If a regular contributor with a one to two year track record of community building or patch submissions would bring up such a topic it would likely trigger slightly different reactions. This does not imply that new, potential contributors are not welcome, on the contrary but it highlights the fact that developers are more willing to listen to people with a proven track record and insight into the project specific constraints.

Lets look at a few examples from this thread:

Q: Why has OpenWrt no update notification mechanism?
A: Because its complicated, the squashfs+jffs2 split makes it impossible to upgrade packages in-place, because the kernel cannot be upgraded on the devices, because there's no formalized system for image discovery, version announcements and so on. Solving that isn't trivial (otherwise it would've been done sometime within the last ten years), requires touching almost every target (harmonizing image names, consolidate image formats, setup server side infrastructure for versioning, ...) requires tight integration with the release builders which in turn requires devops resources we don't have available.

So its a seemingly innocent question with a lot of implications. Now if I would reply with "sure, just harmonize the targets, find a common upgrade format, a version exchange protocol, a way to reinstall packages after sysupgrade plus signature verification and a scalable server side setup with minimal maintenance and don't forget about the privacy implications" you would probably think that I am ridiculing you while I would assume that you'd be gone in a few weeks anyway (don't take that personally, that's just the way it is with the majority of one-time / spare-time contributors, it does not mean that I want you to go away :slight_smile: ).

Another example:

Claim: It seems there is a rush to upgrade the Linux kernel too soon.
Answer: Staying close to new versions is required to be able to upstream things, to be able to support new targets (Raspberry Pi is a good example, it requires loads of patches with kernel 4.9 and 4.14 but far fewer with 4.19), to get access to future subsystems we need (network offloading, DSA, ...) and of course to avoid ending up with a kernel out of support.

What I think you think is "these developers chase the latest version for fun and forget about all those well running devices out there". What I think is "here's someone not aware of the need for the hw offloading infrastructure, the pending switch to DSA, the transition from ar71xx to ath79, nftables etc."

Next example:

Claim: the average device the support to the latest version of OpenWrt seems pretty short, all major versions introduce breaking changes and drop support for a lot of devices, there are not even frequent service releases

I wonder: "Whats wrong with service releases every four to twelve weeks? Why is that not frequent? I've also used my WNDR3700 since the 12.09 era which was in 2013, and just recently updated it to 18.06.1 without major issues."

To me it appears as if you're extrapolating your MT7620 experiences to the entire project ecosystem here.

Then we continue with:

Idea: Let's just solve this with a beta feed program
Response: Sure, but who's going to do it? Contributors right now cannot keep up with the amount of PRs and patches or with backporting all relevant things to the respective branches, who is going to curate the beta feed?

I am all for new ideas and I would really like to see such a scheme implemented, but such a huge endeavor needs to be approached in small steps and one precondition for that would be someone watching the github package feeds and cherry-picking merging all relevant commits on the master branch to the respective release branches.

This is currently done very infrequently and could be theoretically done by any (power) user with a bit of git and compiling expertise, but its boring and tedious, especially when master and release branches diverge over time (you don't want for example replace mysql with mariadb in a stable branch, instead you need to somehow maintain security fixes separately etc.)

Maybe the response should have been "Sure, you can start by help backporting things from openwrt/packages/master to openwrt/packages/openwrt-18.06 and openwrt/packages/lede-17.01" but I am not sure if this is the answer you expected.

If you approach the project with "your support cycle is too low, you don't do LTS like Ubuntu, you don't provide updates, hardware support is bad and you update kernels too often" (no matter of true or false the statements are) you'll most likely see primarily defensive reactions, especially when you don't have a (apparent) track record of working close to the system for a while.

This (imho) has nothing to do with not being welcoming, its just not the most straightforward way to convince people to back ones own ideas with their available development resources.

It is true that meddling in OpenWrt things for years makes one forgetting about how hard it is to get started with it, and how off-putting the terseness of patch replies or the apparent silence can be - so again, I am very sorry if you perceive that as getting ignored or ridiculed.

5 Likes

The kernel is developed independently of OpenWRT (except for backports), so go
talk to the kernel developers about making the kernel more modular.

Everything in OpenWRT is in git and so available to be branched and modified by
anyone interested (and the OpenWRT team is very open to external contributions)

you don't seem to get that OpenWRT has no money to pay existing developers, let
alone to provide anyone else with an 'incentive' to work on anything in
particular.

the different targets are based on the chips, both the CPU chips, and the wifi
chips.

having lots of branches for things that are just config options would cause a
lot of extra work (merging fixes into all the different branches)

many projects have moved away from the 'development' vs 'master' branch
structure and instead just have a 'master' that is getting current development,
with branches for different releases (virtually no development happens on the
release branches, just backports of fixes)

the cost of maintaining different branches that get active development is very
high, virtually no opensource project does this well (a few projects that have
big corporate sponsors and lots of paid developers are not too bad)

David Lang