Maintainers are real people with lives outside of OpenWrt.
Sure. But maintainers are also maintainers, that should maintain. If a PR is without ANY response for 1 or 2 years, in my opinion, the maintainer is not maintaining. And that IS a problem for the sustainability of OpenWrt, because it discourages new contributors and frustrates/scares away the people who volunteer and put in the effort to improve something.
You are free to patch your stuff and build your firmware.
Openwrt is a dev platform. If that's not your style choose mikrotek or ubnt or Fritzbox.
So you and/or "OpenWrt" are actively encouraging people to keep the bugfixes/improvements for themself, after all, why bother?
Please clarify me, I don't know the history or the organization details. OpenWrt is a "dev platform" of some people (who?), that, luckily for all of us, is source available, so anyone can build and modify, like SQLite? So why donations?
If you notice that one of your pull requests falls through the cracks (it happens, for many different reasons), the best approach is a) to make sure that it still applies (or rebase) b) gently nudge those who are regularly working in that area to take a look/ review/ test, don't overdo it, don't be too impatient, but stay on it. The better the description, the less remaining issues (coding style, comments, etc.), the smoother merging can be, the better. Everyone is human, no one likes to say no or nag the author for 'stupid' little changes (busy-work), but stuff that isn't ready (or just complex, needing deeper consideration without an immediate need) wanders to the end of the (mental) queue and is at risk to get lost. Avoid the temptations of the ai, ai descriptions stand out like a sore thumb, implying that the patch needs extra careful review. Don't read that as a complete rejection, just that you need to be extra sure that the changes are indeed valid and correct and don't just waste everyone's time - you need to take full responsibility, no one trusts the mechanical parrot.
It's safe to assume that a PR without ongoing activity will be forgotten after 6-8, maybe 12-, weeks. Some PRs will take longer than that to cook, but in those cases there will be discussion on the PR. No one can wade through stuff older than 6-12 months, most of it will not apply without rebasing anyways.
I just wanted to say, if a patch hangs for whatever reason you are free to build your own images with that patch included. Nothing more.
What's the PR?
They are not mine.
For example, this, that starter with patchs to the mailing list in 2024, and with already accepted reviews:
is so unbelievable that there are already merges accepted to workaround this non-merge:
Or this, kind of important, project (the PRs are, arguably, more complex and nuanced):
https://github.com/openwrt/firewall4/pulls
Sry but usteer is far away from a default installation. It's also a community package. I don't get your point.
firewall4 patches is a different beast but is there really an open merge request which is critical?
I would like LuCI and uci to preserve comments in the config files.
Treat a comment line as belonging to the non-comment line it precedes, or as 'the comment at the end of the file' if there is no such line.
And allow comments to be added/edited/removed for every setting in uci and LuCI as well.
A workaround like a hypothetical option comment 'blah' might be imaginable/ feasible, but dealing with free-form comments programmatically gets really-really difficult.
Oh, I would love that. But from a technical perspective, if you've ever written a config parser and tried to do this, you'll realize it's unlikely to happen because it's so painful. We can dream, though...
I appreciate that it may not be straight-forward. On the other hand, I have seen ini-file/cfg-file editor implementations that preserve comments. I have even implemented one (not open source).
If option comment 'blah' is what I can get, I will make do.
Before I start implementing real comment preservation (not
option comment) for uci, I would like to know if this is something that the maintainers and community would appreciate and maintain the code for. Starting with uci.
I've looked into preserving comments for uci and implemented a prototype that preserves comments in the existing config file when doing one of uci commands 'add', 'delete', 'set', 'add_list', 'del_list', and 'export'.
Limitations of the prototype:
-
The comments that are preserved are the lines before a 'config' or 'option' entry. I have not implemented preservation for comments at the end of the 'config' or 'option' lines themselves.
-
Command 'import' converts the imported file to delta format, which has no syntax for preserving comments, so if the imported file has comments, these are lost. If imported and merged into the existing config file, the existing config file does keep its comments.
Prototype is here: https://github.com/openwrt/uci/compare/master...wififreedom:uci:preserve_comments
Draft pull request is here:
With OpenWrt 26.x getting closer (kernel 6.18 is running great!) figured I'd jump back into this discussion to discuss Bootstrap. It's gets the job done, but there are many community themes that are more performant, look nicer, and format much better for mobile.
Take Footstrap for example, this guy has based the "look and feel" off Bootstrap but it performs 3x faster (even noticeable on my 9800x3d build) and is much cleaner on a phone. Personally I think it should replace Bootstrap for 26.x (minus the cat background let people add a bg on their own), or at the very least his excellent performance and mobile efforts should be merged into Bootstrap.
Just my thoughts for the devs, user experience does matter and there is room for improvement here.
If 26.x is coming closer, as you imply, the very last thing one would even think about would be changing the default theme underneath to something that's not even been merged into the luci feed at all at this point.
I have no opinion about footstrap at all (haven't even looked at it, but neither bootstrap nor openwrt2020 feel slow to me, neither on my tl-wdr3600, VGV7510KW22 or my various rtl838x based devices, to take some of the slowest reasonable devices as example today), but it's just common sense to avoid changes with huge impacts towards the end of a development cycle. Yes, OpenWrt isn't always great at this, but here the steps are quite easy, first get it merged (optionally, for everyone to test easily, in-tree), wait(!) a couple of months, then -as an independent and open-ended step- consider switching the default.
Keep in mind that any new theme adds a major burden on the luci developers, as well as all developers of the small luci-app-* packages, as the permutations that need testing literally explode. This needs explicit buy-in from the major luci contributors to even merge - and even more than that (enormous trust in the developer to keep maintaining it for several years to come) to actually make it default.
DISCLAIMER: I'm not an OpenWrt/ luci developer, I don't speak for the project or its developers, the opinions stated above are my own alone - I'm in no way in the decision making path for OpenWrt development.
My 2 cents.
At least many examples covered by actual code changes on these packages would help adoption because if someone just introduced a debattable change which results in lots of work for everyone else I would assume the orginal author tries at least to minimize this kind of work by for instance doing lots of checks and fixes on the popular packages and or get in contact with those in an early stage.
I can say nothing to slowness of Luci or Luci in general because I don't use Luci since forever 
Cool, but the author made a PR so it's all good: https://github.com/openwrt/luci/pull/8903
That's the way it it should be, and it's been received surprisingly positively - so it's looking good for you, but one step after another. It hasn't been merged yet, nor has it seen much testing.