I also have permissions on github to close and thus triage pull requests. Currently I do not have the time to do triage myself, but if given strong hints to where to look I can then help clean the queue of stale or bad pull requests.
On Mon, 13 Oct 2025, Soeren Apel wrote: > Hi Ladislav, > > I completely agree with your reasoning and conclusions. Historically, the > sigrok project had a division of labor that mostly worked but I'm genuinely > struggling to find a way that works for everyone (including me). > > The two core issues for me are that libsigrok's architecture is > fundamentally outdated and that it is *impossible* for me to review and > merge changes to libsigrok device drivers. Why? Because I lack both the > time to perform in-depth reviews and I lack the hardware to test changes > against regressions. > > On the architecture side, it would make way more sense to spend time on > rebuilding libsigrok so people can write device drivers in languages other > than C - python or rust, for example. While logic analyzers likely need the > performance, a lot of other drivers do not. > > That's why libsigrokflow was born to have a gstreamer-like data pipeline > that is as flexible and powerful as can be. Unfortunately, we never got > very far because it requires forking the gstreamer core library and > modifying it to suit our needs - while Covid-19 hit soon after. > > So what's needed from my point of view? > > - People who can perform PR reviews on drivers and give me a thumbs up or > down on whether to merge or not. > - People who can help me prepare releases by summarizing the commit changes > since the last release. I started making such a list for libsigrok but it > just takes too much time I can't justify spending at the moment. > - People who look at the open PRs and let me know which PRs should be > included in the upcoming releases and which can be omitted for now. > - Someone who is willing to spend some time with me to conceptualize a way > forward in terms of gradual changes to the project architecture and > document it on the wiki. > > Individually, all these things can be done by myself, sure, but the amount > of work is just too much when taking it all together since I need to focus > on project infrastructure first. > > In short: yes, I want sigrok to continue and be successful but it's way too > much work for me to do it on my own. After the server crash earlier this > year I kind of burned out and need to get back into things. Thanks for > giving me a push by writing your message. > > > Cheers, > -Soeren > > > > > > On Thu, 2025-10-09 at 14:58 +0200, Ladislav Laska wrote: > > Hi all! > > > > It's sad that sigrok is not receiving much attention and I understand > > the original maintainer(s) might not have the time or interest to > > continue development. However, the project still works great for many > > use cases and there are a lot of PRs open on github, many of them > > reasonably new - currently being ignored and authors demotivated. > > > > I think the community should offer a helping hand with the project and > > offer at least some basic support in running the project. Depending on > > how the original authors want to be involved, I think it would be a good > > idea to appoint some community maintainers (ideally somebody who > > contributed in the past) and give them enough privileges to merge PRs > > and potentially release new versions. Alternatively, people could > > volunteer to review & test PRs -- I'm up to looking into some, but it is > > unclear if it would lead to something, since not even some simple ones > > are being merged for around a year. > > > > What is the general sentiment about this? Is there a will to help keep > > the project running from the community & current maintainers? > > > > I hope we won't let the project just die, since it's a crucial piece of > > opensource software in the embedded engineer's toolbox. > > > > Best regards, > > Ladislav > > > > > > _______________________________________________ > > 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 > -- This message may contain traces of Truth. _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
