we will probably have to head here: https://lists.openwrt.org/mailman/listinfo
the openwrt-devel mailing list may be the best one, @dante how many layers do you wish to traverse?
I'm not sure if that's the right venue, as it seems mostly development-related.
There's an interesting meta discussion about similar grievances on GitHub from 2018:
It was supposed to result in some review and merging guidelines, taking inactive maintainers into account, but I can't seem to find anything that came out of it.
Curiously someone was complaining about the same issues (slow review, lack of maintainers, etc.) in a random HN comment the other day. They eventually gave up contributing.
There was another GitHub issues regarding a place for meta discussions that didn't get any traction:
Any chance @thess could chime in? Perhaps there were some discussions/decisions since then.
2 Likes
Well, in da mighty arrogance important thing seem to knock at the wrong doors. Bro totally did not get series of lectures to bow low before speaking.
AFAIK the mailing lists are the only place where your message is guaranteed to be seen by the core team, and because openwrt-adm has no description, it may not be even used or monitored. So yeah, openwrt-devel seems like the best fit.
2 Likes
Today I actually took a look at openwrt-adm and looks like it's not competely empty. So maybe it is a better option after all (not sure whether it's being monitored by all team members, though).
That said, I don't understand why nobody from the core team chimes in here. Surely some did see this topic.
Anyway, I am curious if anything happens on this front.
3 Likes
Like you say, I'm sure at least some project members have seen the topic by now (some have even commented). I don't think making a big deal out of this immediately will help with the situation, as it might be the way it is by design: i.e. new contributors need to go through an undocumented gauntlet to earn their stripes. Whether this is healthy for the project or its image is a matter of one's opinion.
I think we should wait and see if any project members consider this topic relevant enough to engage with the community, before going to the mailing list, which I feel is a bit heavy-handed.
That said, I did make an account there and made a draft summary of this post (including your remarks). However, I don't feel like I'm offering any new insights right now, that haven't been discussed multiple times in the past, besides nudging the project members to consider reaching out to the often quite capable community.
Perhaps that could be a good thing to figure out before going to the mailing list: what kind of improvements does a developer community want to see? There were some good suggestions wrt contributions, PR reviews, etc., in that GitHub discussion from 2018, but as I mentioned before they didn't result in any artifacts:
- New package submissions that fulfill the package criteria in 1), are properly signed off and pass the automatic build tests may be merged by any committer
- Changes submitted to maintained packages may be merged by any committer if the maintainer does not raise objections within 14 days after getting notified
- Security fixes may be applied by any committer without maintainer consent given that these fixes do not alter the intended behaviour of the package (e.g. do not combine CVE patches with feature flag changes or (major) version bumps)
- When a maintainer fails to react on submissions for three consecutive months in a row, he gets removed as maintainer from the package
- Committers are encouraged and allowed to merge PRs for any package that qualify for 2), 3) or 4)
- PRs with maintainer objections / requested changes that do not get reworked within 14 days may be closed by any committer
Most of the above is somewhat moot, seeing how only a few active developers have commit access in packages, and most maintainers don't.
4 Likes
This is just a speculation but possibly the roadblock is that organizing people and processes is hard. Especially in environments where there is no strong and consolidated leadership. This should be solvable if the right person is found who is trusted, a good organizer and gets a certain level of freedom to create the processes. I can't tell whether any of this is relevant because I know very little about the core team and how decisions are made by it. But I've taken part in some other volunteer projects before which had similar issues (i.e. lack of manpower, despite existence of a fairly large community, because there was nobody in the core team who could actually create the process of working with the community).
2 Likes
As the OP stated, this is a volunteer organization and code.
Openwrt makes is exceedingly easy for people who probably shouldn't be messing with their equipment and firmware to do so. The issue isn't that the maintainers are busy, lazy, etc. The issue is that these very real people have very real lives.
That being said, beyond that, people build and code for Openwrt based on their individual needs. It has always been that way and will continue to exist that way. There is no way for me, personally, to test out SoC changes outside of the Octeon MIPS64, and for applications, if I don't actively use or need them, I don't ever look at them.
Finding someone with both the ability and time/hardware/need to test out a PR probably will do so, but it isn't always that easy.
For those who are submitting PRs to update packages, I would suggest emailing the Maintainer on the package and giving them a heads up an update is out, or, if you've submitted a PR already, point them to the PR and ask them to test/sign off on it. At least then, someone outside of the PR has looked at it.
People often fail to understand the scope and size of Openwrt. If you want to get involved, I would suggest joining the official IRC and/or unofficial Discord and compile Openwrt from source for your device. This way, you can learn, you can adapt, and you can meet YOUR needs. If they happen to line up with anyone else's, then all the better.
Optionally, we recommend any of the packages that are out of date be removed. Someone will either step up, or the package goes away. I don't think this is very good option, but I will acknowledge it exists.
But, that's just my thoughts.
3 Likes
Submissions should be verified and rejected by the server. I would be surprised if it hasn't been implemented yet.
There is a CI that does the builds/checks (e.g. if a commit is properly signed), but there are no automated comments or cleaning up of stale issues and PRs, that fail those checks and where the original authors don't respond.
imho this is NOT inherent an OpenWRT problem. i see this all over my projects i, sort of, contribute to. maybe a donzen or so.
the lack of manpower leads to "automaic" answers like: "send an PR" (this is the new rtfm where you get users to shut up).
only nice/hot/new features (in the opinion of the dev) get some work, requests/reports on bugs/problems stay open for even (eg on ubuntu). sometimes there is some answer where i even forgot what it was all about (e.g. today from the deltachat project, where the answer was: "Shut up, we wont fix it", in some more friendly words) or the request/ticket gets closed automaticly after some time.
so what happens? users stay away from such warm cozy projects and the code quality will thus lack more and more.
problem imho is: KISS is out. YOLO coding! code is to complex! A.I will save us all (NOT).
just my 2 ct.
1 Like
I don't think it's this bad here. Also: this will never be perfect. However, IMO this can be improved if the project has smart enough and strong enough leadership.
I appreciate your insights. And I have similar stories to share trying to contribute to other projects. However this is adding fuel to the fire, not offering solutions and not inviting project members to respond.
I find this particularly uncharitable when speaking about OpenWrt or its members.
2 Likes
I went through some more past, although interestingly still open discussions on GitHub:
This is turning into some digital archeology.
One frequent participant of the above discussions made an interesting observation (taken out of context):
The constant indecisiveness and lack of communication within the project hurts more than it helps in terms of being "free" (to do whatever you want).
And here's another bit from the same discussion that echoes the same sentiment and, I think, sums up the current situation nicely:
I think the real issue is that there is no process for decision making here. I don't think the main repo is perfect but at least they have a formal voting process. Without a clear decision making process, discussions can continue indefinitely and either nothing gets done or someone with commit access will unilaterally decide to enact some change.
2 Likes
I didn't go through the archeology but I think this quote from @Grommish's comment is key:
What I'm taking from this is that there is nobody with enough influence who would actively care about the health of the project's ecosystem, and a large part of that ecosystem is software built for it.
I understand that the project is maintained by volunteers and it's just one thing they do in their free time. However, this and the net result of nobody caring about the ecosystem is in dissonance with the size of the project. So perhaps it's time to hire someone who would do this job, with help from volunteers.
2 Likes
Disclaimer: Answering as myself, not wearing any hats - as a long-term opensource developer, but specifically not an OpenWrt developer. (and this is a short response, augmenting previously raised topics, not to be meant as an exhaustive answer (I don't have that much time at the moment, but it could amount to the equivalent of a few chapters of a paperback book), which I couldn't provide as not being a project member anyways)
In addition to that:
- everyone knows that the situation isn't great, that PRs don't always (often don't) get the necessary attentions, but there are still only 24h in a day and developers are typically overworked with things they may not care about personally, but still have to do to keep things working
- there is a hesitancy to just close open PRs, because:
- that does demotivate contributors as well
- even if the PR has gone stale (needs rebasing, needs attention to issues raised)
- does the original contributor do this (remaining attentive, keeping up and gently pinging the developers from time to time)
- or do you expect the developers who are supposed to merge it to fix everything beforehand (you can guess how likely that's going to be for things they may not care about personally all that much).
- the older an open PR gets (unless being under active discussion with developers involved), the further it drops down the line
- there are lots of 'issue reports' which don't belong into the bugtracker at all (requests for user support, mere questions, requests for new hardware support, …), all of which drains develop attention and adds to the noise
- 'Jia Tan' has been a very active reminder why opensource projects can't drop the ball and 'just merge' contributions if no one had time for proper reviews
5 Likes
Hi @Dante.
This is a perennial subject - having package-specific maintainers is a plus - but definitely NOT a requirement. ( Not many like to merge some other package maintainers stuff and become responsible for breakage. ) Having a dedicated package maintainer can be counter-productive - waiting around for feedback from a long absent dedicated maintainer is often a time sink. If someone fixes a bug or wants to bump a package? Do it. Break stuff and learn from the process. ( This is why we have reviews )
There's understandably a possibly heightened scepticism or risk-aversion in light of the xz backdoor which crept in. In light of this, code-reviews on small change sets are generally successful.
I think the healthy balance is at least 5 PRs as @aparcar mentioned in 15257.
IIRC, there was a potential for subsidy/reimbursement on the mailing list a while back to attend some of the upcoming European meetings that some of the project members attend. So going to something like that and showing your face might work for commit permissions. Some devs have not attended, but still have permissions simply because they've shown good practice, conservative approach and code hygiene, or been there for a long time.
2 Likes
Being rude won't do any good, I can guarantee you that much.
That said, I understand that this comes from frustration which is experienced by many. And I do think that the current approach to PR's is not working - more needs to be done (see some ideas above).
1 Like
I just show my objective sppreciation of values and strong points of the process.
I wish I could spend time helping in some meaningful way, just not sure what skill level is required