Hi Soeren, first of all, let me apologise for missing this email. While I've seen parts of it quoted and was quite puzzled, I did not look into my spam folder and did not see it in sourceforge (I have 0 idea how anybody can find anything there these days). My mistake.
(The reason is got classified as spam is a failed SPF check on your domain, I think you should look into that.) Now, to the topic. On Mon, Oct 13, 2025 at 11:03:36AM +0200, 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). Nothing to be ashamed of, this happens, people change, interest changes, life happens. I'm also struggling to find time for some of my projects that I used to be very involved in. > 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. That is understandable. Not having the devices is problematic, especially if some of the code needs to be changed. However, I think this boils down to having a community of people that have the hardware and are willing to at least test. Hardware that nobody has... might eventually stop working and be deprecated from the project. As much as it hurts me to remove support for anything, sometimes it's just the smart move. > 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. I actually think libsigrok does not need to be rebuilt. As I already noted in the thread about the interface, it seems pretty thin, so it is possibly a question of metadata and a loader and we can have rust folks produce a binary that provides the entrypoint, is dlopen()-ed and called. Virtually zero performance hit after the initial load. Similar thing could be done for python (I can build a wrapper that runs python in the init and tunnels all the function calls). Also virtually zero overhead (well, except it'll be slow due to the analyzer running in python). TBH I don't see the need or the momentum to such a huge project like this... > 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. ... And the libsigrokflow is an example of not having the momentum. I didn't look into the details and can't say with a clean concience whether the idea is good or not (there doesn't seem to be much code and I did not find a design doc or similar in the flow repo). However, from my professional experince it seems like a bad idea to fork gstreamer and try to modify it. Maybe it's a simple library and it's OK, but my experience with gstreamer is from the media world and it always was a huge headache. Overall, I think having a pluggable architecture would alleviate the issue and would possibly allow to decouple the device drivers. The main benefit there is the testing & development will primarily be done by community maintainers that have the actual hardware. This would possibly speed up the process and make it easier on the core libsigrok maintainers. I'm not sure how much is left there in libsigrok though :-) > 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. Thanks. I'll work on some PR reviews in my spare time. I don't have a huge amount, but I have some interests. > - 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. Does this happen on a wiki or separately? Let's work on it. I usually take the whole `git log --oneline prev..this` and start editing it to something legible by a non-developer. > - 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. Let's do it. I'll start looking into the PRs. Additionally, some of the PRs were reviewed by Bert (according to his email on 21st), I think we should start there and merge those if possible, or try to remedy any issues there. > - 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. I'm in, though I don't know many details about the currenct architecture, I have design enough systems to have a general idea what to expect. Additionally, I really believe this needs to be a general consensus of developers/contributors and should not be forced. I'd also like to hear Bert's opinion on this, since he's spent significantly more time thinking about these issues that I have. Based on the emails I understand there seems to be a rift between yourselves, however I'd suggest we put our differences aside and focus on what's best for the project both short and long term. I've made a mistake by pushing an idea I really wanted to see, just to watch it die slowly due reasons I didn't anticipate (and that included lack of anthusiasm from other developers). > 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. True and I agree 100% here. > 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. I love to hear it. No problem. Also, if you'd like, I can offer a help with server hosting etc., possibly with by providing some space for backups or contributing to the hosting fees. Cheers, Ladislav _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
