Re: Help needed in libgtop maintainership



Hey Robert,

On Sat, 2021-03-13 at 20:52 +0200, Roth Robert via desktop-devel-list
wrote:
Hi everyone,

this mail is a bit long overdue, but better late than never: 
libgtop, the library used for "system monitoring" we use in System
Monitor and Usage is in need of help. 

Due to my lack of knowledge on library development, cross-platform
support, and other related topics, which would be welcome for
development of a library like libgtop, I would like to request help in
taking over the (co-)maintainership of the libgtop module from me, as
in my hands, the library is dying, and not even seeing the regular
releases it would need.

As for the current state, the other maintainer, even though with a lot
more knowledge on the library, is rarely available. As a result of
this, since the migration to gitlab the merge requests are piling up,
and even though I could superficially review them, but based on
previous experiences I tend to miss things which lead to bad
consequences, like build failures, needing reverts of merges.

As for the library itself, it is pretty stable, issues reported are
usually for new features, the merge requests are usually either minor
system-specific bugfixes or completely new features implemented by
passing-by contributors, so the amount of work would not be too high to
keep the library alive (even that would be more what I feel I am able
to do at this point). Of course, if you are brave and creative enough,
there is a lot more work to be done than reviewing and releasing.

Please let me know if you are interested, and I will do my best to help
you out starting on the journey.

I'm not certain that this mail is going to have volunteers flooding
your mailbox, and I'm not volunteering myself, but I can certainly give
advice on some ways to easing the burden.

1) Add a CI to your project

Gitlab makes it super easy to add CI to your project, and you don't
even have to bother maintaining the CI runners yourself. Imagine you're
running a script on a Fedora or Ubuntu machine that just got installed,
install the packages you need, and run the build.

This is one of the simplest CI definition example you can use to get
started:
https://gitlab.freedesktop.org/hadess/rio500/blob/master/.gitlab-ci.yml

This should at least make sure that all the contributions folks make
can build (on one system).

2) It's a library, add an ABI checker

A library is really harder to maintain than an application, because you
don't control all the users of that library, and when things change,
you could be breaking any and all users of that library.

check-abi uses abidiff to make it easier to avoid introducing
unintended ABI changes in merge requests:
https://gitlab.freedesktop.org/hadess/check-abi

This is a short example of using it:
https://gitlab.gnome.org/GNOME/totem-pl-parser/blob/master/.gitlab-ci.yml#L24-27

3) Write tests

And ask contributors to do so as well. Presumably you started helping
with libgtop's maintenance because you worked on something that used
it, this should give you a good idea of what would be good tests to
make sure that your application doesn't completely break down.

If the library needs to have fake devices, you can use umockdev:
https://github.com/martinpitt/umockdev
either in C tests like in libgudev or Python like in gnome-settings-
daemon (and plenty of others) to create those fake devices.

If the library needs a D-Bus service running, you can 
https://github.com/martinpitt/python-dbusmock
to create those services inside a sandbox.

Don't forget to actually _run_ the tests in the CI file. You'd be
surprised how often this happens (usually to me, and before my 3rd
coffee).

Hope this helps get you started on being a module shepherd. A shepherd
because, in the end, you don't need to know everything, and this will
actually help you ask, and have contributors answer questions like:
- why are you making this change?
and:
- why does this functionality need to be in this library?

Cheers



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]