3 ms·
Interesting. I made some contributions to the Zephyr RTOS project early this year, and they had a different approach to the same problems. It seems like Curl m
by ryukoposting 2y ago
Interesting. I made some contributions to the Zephyr RTOS project early this year, and they had a different approach to the same problems.
It seems like Curl makes it the maintainers' job to do the rebasing and commit-style corrections. Zephyr, on the other hand, put it on the pull request's creator. I ended up force-pushing and rebasing half a dozen times because I had to learn all their rules the hard way.
I don't think either method is necessarily better than the other - it depends on the project. Zephyr's approach lets the maintainers focus on more important things than commit-style yak shaving, while curl's approach lowers the barrier to entry for inexperienced contributors.
- zdw 2y agoThere are some code systems that force a rebase-centric workflow like Gerrit, where you literally can't push more changes, unless you want to make separate review requests that get queued (which can be desirable) Coming from those better systems, the review interface of Github feels like a badly implemented afterthought.
- account42 2y ago> Coming from those better systems, the review interface of Github feels like a badly implemented afterthought. This really goes for most of GitHub's additions. Issues, releases, wiki all feel like the bare minimum needed to claim it has those features.
- account42 2y ago> Zephyr's approach lets the maintainers focus on more important things than commit-style yak shaving, while curl's approach lowers the barrier to entry for inexperienced contributors. Depends on the person I guess but I often find it less exhausting to just fix up minor issues myself than to get a driveby contributor to adhere to the project style.
- ryukoposting 2y agoI guess I should clarify - the maintainers didn't poke me to follow any guides. They had a wall of GitHub actions yelling at me in their stead.