I'm quite surprised how people are deadset on something called release just for the sake of it (it seems), if you want to run something more "fresh" you have snapshots which usually works fine.. As I've said before, looking at backports very few contributors "cares" about releases anyway (backporting) so it probably boils down to interest in general.
-
Think about issues. Is not it easier to track bugs in a known version, than if everybody has different versions of maybe both official (and non-official) build?
-
You should not backport new features, only fixes. That makes sense. And that requires often releases, but I've already written about it.
-
Watch how much space is wasted by these tens of versions - one example: https://downloads.openwrt.org/snapshots/targets/mpc85xx/generic/kmods/
2 Likes
The thing is, most people do not want to download Gigas of data, to then configure and compile the code (let alone many people have no clue of what compilation is).
Maybe it could be possible to generate further "stable" builds - after an initial xx.yy version is released - every 3 months, automatically from the last snapshot in that main version? E.g. 18.06.2 now, then 19.01 manually in Jan, then automatically 19.01.1 in Apr, 19.01.2 in Jul etc...
Openwrt/Lede is an amazing work, from which we all benefit. Thank you again.
It's a nightmare to do. Other distros have security teams. OpenWrt does not.
To say nobody cares about releases is incorrect. There was a recent mailing list email where it was requested that LEDE 17.01 get further support.
I personally think the snapshot model works better for OpenWrt as it is right now, bleeding edge is rarely imported apart from WireGuard more or less so it should be "safe" in most cases. To my knowledge there's no release testing procedure apart from branching it off and label a few versions BETA/RC (no constistent regression testing etc). Of course devs have a some devices on their own which are run-tested but I as far as I know there's nothining more than that. I could be wrong but I've never seen any documentation about the release procedure other than BETA/RC.
Perhaps something like quarterly snapshots (releases) with minimal backporting effort (security and major fixes)? That's pretty much what buildroot does as far as I know. In fact, I think they stick with monthly snapshots/releases.
There is no management in the OpenWrt project, maybe this is what causes people to have a wrong perception about things. If you want an incorporated entity with deep pockets, full time employees and a strict, professional organization, then use OpenEmbedded instead.
http://lists.infradead.org/pipermail/openwrt-adm/2018-September/000901.html
http://lists.infradead.org/pipermail/openwrt-adm/2018-August/000866.html
http://lists.infradead.org/pipermail/openwrt-adm/2017-May/000513.html
http://lists.infradead.org/pipermail/openwrt-adm/2017-April/000448.html
http://lists.infradead.org/pipermail/openwrt-adm/2017-February/000366.html
http://lists.infradead.org/pipermail/openwrt-adm/2016-December/000314.html
This is plain wrong, please stick to the facts.
OpenWrt 18.06.1 was released just about three months ago and LEDE 17.01.6 about two weeks later. Are you seriously claiming that we made false "never ending promises" about maintenance releases just because there's been no release since 10 weeks? Do you realize that there's been times where there was no release for years?
Statements like this make me extremely angry and cause me to question the sense of putting that much energy into this project.
When did releases stop? It would help a lot if people wouldn't start ranting and start spreading plain wrong misinformation and uninformed guesses just because a release is overdue by a few weeks.
You do realize that there's currently like three to four regular people maintaining all targets for all branches? If this mode of operation does not suit your needs then fork OpenWrt and feel to implement the project in a better way, with professional management, full time employment and regular releases with task priorities and roadmaps, all while still developing it of course.
Having stable releases and frequent feature backports are mutually exclusive requirements. You do realize that a lot of regressions are introduced upstream by updated kernels, toolchains and package updates? Are you also aware that new features require new versions which come with a higher footprint deprecating existing support for older devices?
For those that want latest features, there's snapshots available, even without compiling. For the others there are regularly updated binary package repos and timely minor release in the wake of larger security issues.
14 Likes
I do not like the snapshot model at all. There are weeks when bleeding edge package bumps introduce more regression than we can keep up with, each new kernel version breaks more things than what it fixes and don't get me started about the quality of initial major GCC versions.
Just because some poster child shiny ARM box with huge amounts of resources has no issues dealing with the latest stuff, this does not mean that this is a viable model for the majority of supported devices.
5 Likes
It does have its pros and cons for sure, I'm curious what would be the best approach in the end.
As far as I can tell kernel versions are more or less the same for both branches so that seems fine? One of the major hurdles with "stable" vs "master" seems to be that they quite often diverge in such a way that when there are regressions they may already be fixed in master and it's quite a task to backtrack unless it's a very specific regression and viceversa. Having more frequent release cycles would probably help minimize the gap between bug reports and current code.
FFmpeg "solves" this by requiring testing to also occur on master if there's a bug in the current release as they appear to have similar issues when it comes to backporting/backtracking. I think u-boot also handles it in similar fashon but I haven't looked closely.
This is still far better than picking the latest snapshot. I've tried that once, and I had much more problems than I've had with any release version. With releases there is a warning in advance, and the developers can make sure their commits are in a consistent state and that the latest security fixes are included.
I realize that nobody guarantees that any of this happens, but I check the commits and discussion that has happened before a release so I get a pretty good idea of what the state of it is. On the master branch that is not really possible because nobody expects it to be consistent or stable.
Please, don't. There are tons of us who love this project, appreciate all the efforts that the devs are putting here, and are very grateful for they unpaid time you spend on this. Do not let one rude comment spoil all the fun.
12 Likes
Due to amount of supported devices (to various degree) I think it's inevitable which also can be seen for releases as well. On some occations I've noticed breakage on master but that's quite rare (for me at least) but some devices are more exotic than others. The idea/question is more or less if release cycles should be shorter which could possibly lower the work load and easier to track/backport/bugfixes.
@neheb
Please read that again, given the lack of backports I do get the impression that the majority runs master and finds it tedious/timeconsuming backporting. I should also mention that I haven't looked in detail at all commits but I'm quite sure there are ones that fall into the security/bugfix category which doesn't get backported.
eduperez I came here to say the same thing! Jow thank you for all your hard work mate. If I ever win the loto I will send you lot a bunch of ££ 
I can't speak for the community maintained package universe but OpenWrt base does get security related backports.
You took my opinion personally. I am sorry about that. I use OpenWRT and take advantages of it. It makes a sense for me and many users, as you see here. Also many projects fork OpenWRT.
OK, updating userspace packages seems to solve the problem, but what about kernel modules? A good example on 18.06 branch are mt76 drivers, which changed status for some users from unusable to working.
If a security fix is a reason for tagging new release, than maybe you could consider repairing the kernel driver as a reason for the new patch release too?
Yes, I am a software developer. I also ported OpenWRT and Gargoyle to some other unsupported devices (including kernel mode drivers) - I know how much work is with that.
I consider it a very good decision, even I have such.
I got a ping about this thread so I'll update it myself. 18.06.2 is planned to be released on January 15th: http://lists.infradead.org/pipermail/openwrt-adm/2018-December/000973.html
A preliminary changelog: https://openwrt.org/releases/18.06/changelog-18.06.2
5 Likes
thanks a lot as usual
" 18.06.2 is planned to be released on January 15th"
Good news.
Openwrt runs my routers for 10+ years
Thanks a lot for key developers like jow. Please ignore some negative comments, they are inevitable in life anyways.
2 Likes
It has been postponed to the 25th.
2 Likes