Open invitation for new team members

[jonasmalacofilho]

Hi all,

In the almost 5 years since its creation, the liquidctl project has been maintained mostly by me.

I've had some help, sure, from @MarshallAsch, @aleksamagicka, @amezin, and other driver authors and contributors. But so far it has remained, in essence, a one-person project.¹ And I think it's time to change that.

All areas of the project could use new team members:

• issue triage and follow-up;
• reviewing of pull requests;
• bug fixes;
• new features;
• new drivers;
• addition and checking of type annotations;
• refactoring and polishing of the codebase.

(There's also an idea for a liquidctl 2.0: a different architecture – possibly daemon based – and implementation – possibly in Rust²).

So please comment here, or write me an email, if you would like to join the team. Of course, for most of the areas mentioned above, you can just get started right now, and we'll make it official later.

(A way to get reasonably up to speed is probably to read the open issues and pull requests [and their comments], check out the developer documentation in docs/developer, and familiarize yourself the codebase. Once you get started, make sure to also check out relevant old issues and pull requests, as well the commit history of relevant files).

In the meantime, I ask users and contributors to accept a higher delay in all activities of the project, but especially in the triage of new issues and review of non-trivial pull requests. Further, please consider the next planned³ releases as postponed.

Thank you,
Jonas

Footnotes

1. This doesn't apply to our sibling project liquidtux, which is much more decentralized. But new contributors are welcome there as well. ↩

2. Although @amezin doesn't (or didn't) agree on that point. ↩

3. We usually do time-based minor releases every 13 weeks. ↩

[aleksamagicka]

(My 2c since you tagged me)

As for me, I've been subscribed to all activity on this project for some time and I do read most of it. I definitely plan on enhancing the Aquacomputer driver further, there's lots of stuff to implement and an open PR to revise. And of course, the nzxt-kraken3 work is ongoing, although I think I'll resolve it all soon, as I've been finishing up other projects that required undivided attention.

As for liquidctl 2.0, if it's in Rust I'm probably not going to be of much help - unless my future workplace requires, I don't plan on tackling it (famous last words).

If I understand correctly, liquidctl is now in semi-hiatus mode?

[amezin]

As for liquidctl 2.0, if it's in Rust I'm probably not going to be of much help - unless my future workplace requires, I don't plan on tackling it

Same. Rust is a purpose-built language - when you need high performance and reliability at the same time. RGB/Fan control software needs neither of these IMO (it just shouldn't be annoyingly inefficient). And reliability has its cost in development time and effort (Rust basically forces you to write highly reliable code). In practice, nothing bad would (or at least should) happen even if a RGB/fan controlling daemon restarts.

So yes, I'm still opposing Rust for this particular project. There are other reasons, but I believe this one should be enough.

And Python should allow transitioning existing drivers to the new daemon architecture. Yes, I believe (based on nzxt smart device driver) that existing liquidctl code needs a refactoring, but not a complete rewrite.

I've experimented with GLib/GObject and C - because there is pygobject, and because GLib's event loop can be used for HID devices on Windows and Linux as is.

But a pure-Python (+ctypes, asyncio) implementation is possible too. Rust implementation would require a lot more time and effort IMO.

BTW, if you need any help with existing liquidctl - especially in areas of CI, test automation - let me know.

[jonasmalacofilho]

@aleksamagicka ,

As for liquidctl 2.0, if it's in Rust I'm probably not going to be of much help - unless my future workplace requires, I don't plan on tackling it (famous last words).

For now a 2.0 is just an idea, and it being written in Rust is not even that.

I feel that if we decide on a big rewrite (not for the language, but for the new architecture), then we might also want to reconsider the language (and Rust might be one contender, besides keeping it in Python, or using something else).

Even then a big factor would be what languages the team members are comfortable with, or willing to learn.

If I understand correctly, liquidctl is now in semi-hiatus mode?

Not yet. For now I'm just admitting that I don't have the bandwidth anymore to promptly react to every issue/PR/discussion. A hiatus is indeed a possibility, but only if the bus factor remains one during the next few months.

---

@amezin ,

I disagree with a few things you wrote, but we don't need to discuss them now (see above my response to Aleksa regarding the mention of Rust).

BTW, if you need any help with existing liquidctl - especially in areas of CI, test automation - let me know.

Our CI setup is nothing to be proud of, but I don't think it's a critical problem.

Besides bug fixes and some long ago planned features (and, to a lesser extent, drivers), the codebase (including the tests) needs some cleanup and refactoring. Plus something I forgot in the original comment: type annotations (and type checking in CI).

[jonasmalacofilho]

@Serphentas is joining the team. Thank you, and welcome!

---

Also, thank you too, @aleksamagicka! This year you've been much more active than me both here and on liquidtux.

[aleksamagicka]

Hi @Serphentas! Glad to have you on board.

@jonasmalacofilho Thank you! I plan to be more active than now, there's lots of stuff to implement.

[Serphentas]

@aleksamagicka thanks for the welcome !