Am Mon, Nov 03, 2025 at 02:01:30AM +0100, schrieb Hauke Mehrtens: > On 11/2/25 18:22, [email protected] wrote: > > @Jonas, you can review them and add your review comments and also add your > > approval, if you think that the PR solves an issue and is in good shape. > > Therefore, more eyes on a solution, the better it is. > > Thus contributing to the overall effort to maintain the project and the > > components.
I am not used to this concept. But yes, I can try to pick some PRs and take a look at them. The most demotivating result would be when I give positive feedback and nothing happens afterwards. > > Most people are doing this because the care in their spare time. > > Forking leads only to more fragmentation IMHO. Right now, whenever upgrading OpenWrt, I manually apply some patches. A fork would make this easier. > > Unfortunately to my knowledge there are many commercial downstream users > > and even whole foundations, with, to my preception, little giving back to > > the upstream. OpenWrt. > > This is my view as a contributor, based on discussions and commit sign-offs. Regarding fork developments, I have seen one so far [1]. A fork tried to upstream something and no one reacted. In this case, the author is not working for the project anymore and stopped working on this after six months passed. How motivating is this to try to upstream the next thing? Am Sun, Nov 02, 2025 at 02:46:37PM -1000, schrieb Philip Prindeville: > No, I've called this out before. I only looked at the two new PRs. The issue referenced in one of them [2] does not tell what you've written in the list now. I made the mistake in the past to have a good commit message but bad PR description. This issue does not exist with patches sent to a mailing list because then the commit message is always clearly visible. But I also experienced the problem with contributing to core [3]. After reacting to feedback, nothing happend anymore and it was required for some use in a package. I also know that PR in odhp6c that needed changes to multiple repostories where no one reacted soon after it was created. Maybe a monorepo structure would make this easier as it allows commits to span multiple components at once? This would make it easier to show in my case and in your one what a change in the core is good for and it reduces the amount of review processes that don't feel linked together. [1] https://github.com/openwrt/odhcp6c/pull/96 [2] https://github.com/openwrt/libubox/issues/15 [3] https://github.com/openwrt/openwrt/pull/14333 _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
