Hacker News Reader

Comment by v1ne | Hacker News Reader

I don't know. My experience as a contributor to Sigrok was sad: I significantly improved a driver and wanted to upstream those changes, but was met with "well, the maintainer has little time, can you slice your changes into smaller pieces?", and honestly, after a months of doing that, waiting weeks for feedback, explaining things, I lost interest. Also, with time, I honestly don't remember some details of the changes beyond what's in the commit messages.

I also found the style of the code quite antiquated, without any wish to change that. But that's my taste.

So, in the end, my work on that driver felt wasted.

View on HN

Your OLS improvement patch set was huge, and a challenge for anyone to review. But you're right that it took much too long to get any traction, and I don't blame you for getting discouraged.

Having said that, you did eventually get a ton of comments, by a trusted and well-respected contributor (wsa), but I guess you'd already given up by then, so didn't respond.

How about this: make the changes requested, and I'll personally take on further review and/or approval. I'm the original author of the OLS driver, and of course I have the hardware, so that's as good an opportunity to get your code in as you'll get.

Oh, thank you for the offer! I'll pick it up again and update the PR. Haven't looked into it since then.

I found the OLS, especially with the Demon Core, a really neat piece of hardware.

"can you slice your changes into smaller pieces?"

You don't send a huge patch to a project as a first time contributor.

I am sure sigrok would benefit from your improvements, but sometimes the maintainer has a busy life outside the project so you need to adapt to their pace, at least in the beginning.

I would agree without even the caveat of the maintainer being busy. When a maintainer receives a massive changeset they have to then recover why the task was taken on in the first place and understand any decisions to get to the same outcome presented in the changeset provided. The more logical complexity that this change represents whether it is 3 lines or 3000 lines still needs to be understood by the reviewer as not breaking the rest of the system and equally can be 'massive.' The further you get from an N+1 change into a N+5 or N+6 change is where you get into situations where a N+3 change is flawed based on the rest of the system and invalidates large parts of the changeset, and that doesn't resolve all the issues or concerns.

I think a lot of people forget that changesets are sometimes not the most straightforward way to express ideas. They (including myself) also forget that while you are working with a change in front of you it's obvious but in one month it could be opaque. A maintainer is often giving you the perspective of you a month later who built on this system you changed.

For something like drivers most of them are probably from first time contributors, and they aren't really going to be hanging around for further contributions.

That's fine - the driver would improve if the contributions are accepted, and they don't touch core code that will break other things. But instead totally non-functional drivers are left languishing because PRs aren't merged.

In the case of Sigrok the problem didn't seem so much the maintainers, but rather non-developers "triaging" PRs with unhelpful advice to split patches, when a lack of actual developers meant they'd never be looked at anyway. Otherwise a fork might have occurred rather than wasting everyone's time.

I wish projects would be more strategic around acceptance rates on drivers/plugins contra core. On plugins etc one should have much lower barriers to contributions, compared to on the core. It is actually one of the primary reasons why such architectures are beneficial in FOSS projects.

> You don't send a huge patch to a project as a first time contributor.

Although that’s a good guideline, it’s not true in absolute terms. Sometimes the contribution is a big patch!

And sometimes the best way to contribute is by forking. Depends on the situation for sure, but this encourages an acceleration by the maintainers of the original library. If they don't have the time to do so, they can comfortably ignore the fork.

On GitHub most PRs come from works though? Or do you mean make an entirely separate driver?

I do appreciate your contribution but I'd also like you to ask for some understanding of the project's struggle as well. Aside from the loss of members due to personal interests shifting, the project has to make sure that all changes do not introduce regressions. We do not possess all the hardware that the drivers support, so when someone wants to change the code that affects multiple devices, we have to be very careful and thorough to make sure that these changes don't make other devices supported by that driver stop working.

Sometimes, when the changes are too big to make a decision by code review alone, we need to rely on user feedback. Unfortunately, this is always a challenge as there aren't a lot of users around who are willing to test changes.

I hope to improve the situation by allowing the CI/CD pipeline to provide binaries for PRs so users don't have to build from source.

Either way, your efforts aren't wasted and I appreciate anyone wanting to help out.

Sigrok project is dead... There is a single maintainer and he's not willing to merge almost anything, it's been like that for years. I think it's time to fork...

While I acknowledge that the project was without effective leadership over the past 2 years, I'd appreciate if you wouldn't mix up "willingness to merge" with the ability to do so.

There are a lot of pending changes that I simply cannot review or verify easily since I don't have the hardware the driver is written for. Asking for help has never really been met with much enthusiasm, unfortunately.

Either way, I'll get to these as soon as I can and help is definitely welcome.

Reply on news.ycombinator.com