Hi! This is definitely true, but overall I'm actually surprised by the quality of some of the PRs, but also on the community review posted.
In many cases, the PRs are small enough or self-contained enough so it would be OK to squash the commits before merge. Especially when adding a completely new driver, I frequently find it's easier to just check out the code and go through it all, unless the original developer did a _really_ good job splitting the history for easy merging. This is relatively common in the linux kernel community and is really nice to see. Regardless, I think it's fair to ask the contributor to rework the code according to the standards - and if he doesn't, somebody else could build on top of those changes (crediting the original author). In simple cases, the project owner can usually modify the PR as well as the author, and can perform some simple changes. I've done this multiple times if it's a small thing like poor formatting -- in that case it's easier to just fix it than to explain the issue. In any case, it _should_ be written down and not ignored. Best regards, Ladislav On Fri, Oct 24, 2025 at 06:19:07PM +0200, Dan Horák wrote: > On Fri, 24 Oct 2025 11:20:35 +0200 > Ladislav Laska <[email protected]> wrote: > > > Hi All, > > > > Based on the conversation here, it seems everybody wants to keep the > > project running, so let's make it happen. > > > > I'd like to start a review crunch of the PRs on github, with the idea > > the project could release a decent version, ideally by the end of this > > year (we can think of it as a christmas gift to the community). Anybody > > willing to help? > > > > Please post here if: > > > > 1. There is a PR you've already reviewed and believe it's ready for > > merge. > > > > 2. There is a PR you want to review & test to help out the project. > > (this is to so we divide the work properly) > > > > 3. Have special interest in some PR (fixes an issue you're facing, adds > > support for hardware you have). I'll try to look into those if they are > > within my skill set (or somebody else can pick them up). > > > > ... or if you want to help in any other way. > > one issue I see with many projects is that PRs are not following the > project's standards (doesn't have to be written down, just follow the > example) for writing commit messages and splitting the changes into > individual commits. Which makes it difficult to follow the development > in the mid/long term, especially when multiple developers and > maintainers should be involved. It also affects the willingness to > review other people's PRs/code. > > > Dan > > > _______________________________________________ > sigrok-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sigrok-devel _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
