Reasons for frequent major kernel upgrades

My shiny new router with the latest SOC, supported only by kernel 5.15, should remain on the shelf waiting for a kernel push that will not come as an old 4MB device needs to keeps ticking, or kernel 4.x is somehow perceived to be more stable. If there is an issue with a current kernel it is a bug that needs to be addressed.

5 Likes

Fair point, all those things are to be considered.

How many new devices will be supported after an upgrade? How many will behave weirdly?
How big is each userbase? What are the fixes? Can we wait out? And many other questions are to be asked for the best outcome.

One of the issues that I've not seen mentioned is the fact BUILDING OpenWrt requires resources, and resources cost money. Real-world money.

Whether it is someone who is donating the server time, or the build-bot knowledge, or just the time involved to keep it up and running across so many targets. There is an expectation that once you outgrow your toys, they have to be put away.

My device has THREE separate kernels and independent storage space, allowing for the user to hardware switch Triple boot options. It was deemed (rightfully) that the resources expended on creating DAILY Snapshots of 3 devices that, statistically, no one will ever use, is silly and wasteful. So, OpenWrt only supports the one boot option officially. (I maintain my own local repo that adds that functionality back to my own builds).

Resources are limited and they have to be allocated as appropriate - be it human cost, time, or money.

2 Likes

So you are suggesting that OpenWrt cap the number of new devices or what?

I really think you are still misunderstanding the point of open source projects, this is not your company-run project where you can impose things like that, test everything new on all supported devices, know your userbase size etc.

How would you know the userbase size of OpenWrt?
I mean you can guess which targets are more popular but I don't think that you can really have some exact numbers.

What do you mean by wait it out?

As @Grommish explained, this is fully voluntary and free but even so, it requires resources to maintain it, be it developers or buildbot VM-s

1 Like

Ehh.. again.

So you are suggesting that OpenWrt cap the number of new devices or what?

No.

I really think you are still misunderstanding the point of open source projects, this is not your company-run project where you can impose things like that, test everything new on all supported devices, know your userbase size etc.

:joy:

  1. The topic has been solved
  2. You miss the point of open-source it seems - anything can be done and improved, if you cannot comprehend something it doesn't break open-source
  3. You are the only person imposing anything, in this case that given topic cannot be discussed.
  4. Gargoyle gathers statistics for 7 years now, not only that, but i don't say OpenWRT should do the same, it's just a possibility, not even endorsed by me, just brought up as a factor in a bigger evaluation of certain motives.

As @Grommish explained, this is fully voluntary and free but even so, it requires resources to maintain it, be it developers or buildbot VM-s

Why do you bring it up? I've already upvoted what @Grommish has posted and agree with the person, brought a very good point that supports longer cycles.

A fork of Gargoyle for its Polish userbase has been doing this.
And the topic has been raised here several times, and people are too privacy focussed to give away such statistics.

2 Likes

Sure, that's a decision to make on your own, i personally have little problem with GOOD telemetry.
Most open-source projects would benefit from some.

I don't understand how am I imposing anything on you?
You are free to discuss whatever you want, I don't see how can I restrict your freedom.

I may come off as rude as I get pretty annoyed when people come with the "recommendations" for improvements that are either too vague, "make wifi better" style, or made without actually looking into whether they are possible before.

Do I think there are things to improve?
Yeah, obviously, and multiple ones.
For me the migration to a new LTS is too slow, wireless backports are too slow and they even tend to be older than the generic kernel that is used.
And my biggest one is that it takes too long to merge anything, this is mostly since I work on IPQ related targets that arent that hot with the maintainers but are really popular with users.
And in the end it all comes down to developer time and more precisely lack of it and people with commit rights.

When it comes to telemetry, then you will probably newer see some kind of telemetry being collected due to privacy concerns.
I agree with that, as to why would a regular user have to go into source code to see and understand what kind of telemetry is actually being gathered.

1 Like

Just curious...

What is your experience working on Open Source projects?

Ad hominem.

It's long and varied.

Last response to your post, as it's pure waste of time.

There is no argument, no substance in this post except for

And in the end it all comes down to developer time and more precisely lack of it and people with commit rights.

EXACTLY! That's what this thread is ALL about if you actually try to understand it and read the selected solution.

Since there's no technical steering committee in OpenWrt, development directions are based on lose consensus and driven by the developers being active in the particular parts of the system. Those OpenWrt contributors involved in kernel level work prefer to stay close(r) to upstream instead of backporting features, hence the frequent kernel bumps.

4 Likes

By the way, even if i was not contributing they your fallacy is even bigger than ad hominem, it's actually two fallacies in such a short post.

I know you've said "just curious..." but without this part it might mean that people who aren't cooks cant review food and so on.

Edit: also just the act of discussing something with critical thinking is contribution in itself, actually that might translate into more improvement than changing some lines here and there

It's auto-generated

I really don't get you at all.
What kind of arguments do you need more?

In the first reply, I wrote that it all comes down to developer time and not wasting time to backport things even further.
It's the only way to keep this project maintainable along with upstreaming to the kernel.

That is obvious, this post discussed pros and cons of such decision.

Is it? Your initial post posed these two questions:

and

I believe these have been answered by now. Maybe change the thread topic to something like "discussion about kernel update policy" if you would like to discuss the topic in general.

1 Like

Your questions have been asked...and answered.

It is the way it is...for the reasons given.

You've been a forum member for 5 minutes, and starting to look like a troll.

Tread carefully.

Can't speak for all fellow developers but in general some of the primary motivations for pursuing recent kernel versions are:

  • bringing existing out-of-tree functionality upstream and re-import it from there through updates
  • bring in new functionality (for example flow offloading, DSA, board support, netfilter, eBPF)
  • spread the effort to migrate to the next major kernel version over many intermediate updates instead of less frequent large ones
9 Likes

We have download statistics on the homepage. But it doesn’t say how many users we have and how many devices openwrt is installed on.

You can download one file and install it in many devices, or not at all. You can download source code and compile freely. You can download imagebuilder and make many different images for different devices.
We also have router manufacturers that use openwrt based firmware.

And one of the fundamental legs the project stands on is the security and privacy so we cant have spyware in the sourcecode “calling home meta data” so we know who and where the firmware is installed.

2 Likes