Hi, At least for protocol decoders, why not using this classification? https://askubuntu.com/questions/468875/gstreamer-plugins-ugly-and-bad
If a protocol decoder passes basic automated testing and some linting rules, simply merge it as "bad" or "ugly" and wait for users to complain. This proposal is still compatible with the code-review approach and a protocol decoder can perfectly make it to the "good" category straight away if required. I personally committed 2 protocol decoders (HDMICEC / NRF905) and in both cases got warnings on the code reviews that I was not aware of them being some kind of "rule", so if I was reviewing some other person's code I would have slipped those problems anyway. Regards, Jorge. On Thu, Dec 1, 2022 at 12:52 PM Karl Palsson <ka...@tweak.net.au> wrote: > > "PlusNET: Subs" <s...@qcontinuum.plus.com> wrote: > > > > f) for the review stage, anyone can go to the relevant Sigrok > > repository* and review the submissions > > This is one of the items Gerhard raised as being an issue that > the community should be helping with, and that (IMO obviously) > not everyone else is/was aware of, but it's not that simple. > > Yes, _anyone_ can do a review, but from experience, in this and > other projects, the _only_ thing a "community" reviewer can grant > is a negative. (This doesn't even work, it breaks on my machine, > etc) A _positive_ community review is worthless. It won't get > anything merged, and it won't help get anything merged. Because > of this, there's _very low_ motivation for community review > outside of patches that explicitly affect the individual. This in > turn leads to very few community reviews, which lead to core > people being grumpy that the community isn't "doing their part to > lighten the load" and it's a downward spiral.... > > > > This gives rise to a number of questions/requests for > > clarification: > > > > 2. What are the thresholds to get > > the code accepted? Number of comments? Sufficient time elapsed > > for reviewers to comment? All issues that have been commented > > have been addressed? All of the preceding? > That's it. At the end of the day, it simply doesn't matter how > "involved" the community is, how many reviews they do, it's still > 100% in the hands of the people with commit access. And > regardless of policy, as you can see, it's largely arbitrary. > Which yes, spares the sanity of the committers, but at the cost > of the sanity of the "community" > > Solutions? None. Committers must be allowed to be busy and ignore > things. > > Perhaps, just perhaps, a committer promise of "we'll look at this > once there's been a community review" could be a start, but > that's a big promise and a lot of faith on all sides... > > Sincerely, > Karl Palsson_______________________________________________ > sigrok-devel mailing list > sigrok-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sigrok-devel >
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
