On Mon, 2022-10-31 at 17:56 -0600, Paul Kasemir wrote: > > One more try, can I please get a developer to review: > https://github.com/sigrokproject/libsigrok/pull/144
There seems to be confusion or uncertainty how to do a review. So let me outline how it could be done. In the specific case of PR 144, a possible command would be: $ git log -p --stat --reverse ea9cbb6c2f2d..94a79f90b947 This requires looking up the hashes, which could be inconvenient. Let's try something more convenient and more portable, with symbolic references that humans can memorize. This assumes that you already got a clone of the repo. $ git remote add -f github https://github.com/sigrokproject/libsigrok $ git fetch github pull/144/head:pr-144-mso19 $ git log -p --stat --reverse pr-144-mso19 ^master Don't prefer the command line? That's fine, too. Use any tool or UI that you happen to like. Even a web browser might do if you feel that way. Whatever floats your boat. I was told that github has interesting constraints. Would not present commits to you in order. Might "beautify" and thus falsify the information that git actually keeps. May not let you easily inspect the commit series, might instead focus on some resulting source code after the last commit. But if that is true then these would be github's deficiencies, not the git utility's and certainly not the sigrok project's limitations. There may be workarounds, obvious or secret. I don't care, git is available to those who want it. As are other UIs. Just find one that suits your purposes. Once you got that data, you do the look then think then speak sequence that I talked about elsewhere. Have a serious look at that information. Try to see it from the recipient's perspective. See it as a request to accept responsibility for future maintenance of what is submitted. Would _you_ accept what is provided, and the cost that is involved in picking and keeping it in your code base? If you would not, then why? Speak up. Use information that was communicated in previous reviews and other submissions. Use the experience that you got from developing other software. sigrok is not at all special in that regard. That's how you can help improve the quality of pending submissions, and raise their chances of getting picked into mainline. Where the code then affects all users, should work on all supported platforms, and cover several different use cases. Not just scratch one individual's personal itch and match their local setup but nobody else's. That's why quality does matter. It's in the interest of users to not lower that bar, and burden maintenance more than necessary. The symbolic approach above easily translates to other PRs. Have a look at them, too. See if you can help, and how you can help. And let me repeat: Doesn't take a sigrok core developer to do all of this. Any user can read and comment. Given the very technical nature of the project (it's a software for signal analysis after all), I just don't swallow that none of the users has experience with software or how to develop it. And doesn't know anybody else who does. And cannot spare a few minutes. And doesn't know how to speak about what they've observed. That's just too strange an idea, and rather improbable. At least those issues in pending submissions which aren't sigrok specific should be possible to spot and comment by any number of users. So consider lending a hand, if you really care about the project's progress. Or wait until somebody else gets around to it. At the pace that the few active people can keep who are currently left to the project. Whatever works for you. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
