[Slackbuilds-users] Maybe Taking Over Some Packages

[B. Watson]

On Sat, 14 Sep 2024, lumin--- via SlackBuilds-users wrote:

>  system/busybox
>    Maintainer mail server timing out,
>    package behind many versions.

Jan F. Chadima hasn't been active since 2020. Go ahead and take this
one over.

Looks like Chadima has a lot more builds that need maintainers. Anyone
reading this is welcome to grab them. List here:

https://slackbuilds.org/advsearch.php?stype=maint&q=jfch%40jagda.eu

>  graphics/feh
>    Maintainer was contacted, they said they
>    haven't been active on SBo for a while,
>    and that someone should take feh over.
>
>  graphics/optipng
>    There was discussion about it being
>    vulnerable and unmaintained, seems
>    urchlay updated it, but I can help
>    with this one if he wants.

I took both of these, rather than see them go unmaintained. But, if
you're interested, you're welcome to them. I have 900 builds already,
I won't miss these :)

One request: please base your versions on my updated versions.

> A few questions on the responsibility
> of a maintainer:
>
> 1. Is there any comprehensive guide on that?
>   A link to said guide would be appreciated.

I'm working on writing such a guide, but it's not finished yet.

The short version: when you maintain a script, you're responsible for
responding to emails from users, helping them with any problems they
may have. You're also responsible for keeping the script updated,
when the software updates... though you don't have to "knee-jerk"
upgrade as soon as a new release comes out. You want to do some actual
testing, make sure the upgrade doesn't break anything. *Especially*,
you have to make sure your upgrade doesn't break any other builds
that depend on yours! Use the "advanced search" on the site to do a
Dependee search, to find out what depends on your build.

There are tools to help you keep your builds clean. Use sbolint and
sbopkglint from sbo-maintainer-tools to check them.

> 2. What platforms should I test for?  Is a
>   clean chroot or VM of x64 stable enough
>   for now? or should I test on x86, arm,
>   -current combinations?  Personally I
>   currently only use stable x64 15.0.

Please test on 15.0, on both x86 and x86_64, clean environment (chroot
or VM).

I recommend testing on both a clean environment *and* a "dirty"
environment with lots of other SBo packages installed (to catch
conflicts with other builds), but not everyone agrees with me that the
dirty testing is worth the effort.

We don't support -current, so don't worry about testing there unless
you really really want to. There's an unofficial fork of the SBo
repo, run by Matteo Bernardini aka ponce, where fixes for -current
are gathered.

We don't support 32-bit arm, and never will AFAIK. We have plans
to support 64-bit arm (aarch64) sometime after Slackware 15.1 is
released, but even then, maintainers won't really be expected to
test everything on it. Not everyone owns the hardware, and emulation
is painfully slow. All that'll be required is, if an aarch64 user
sends you a patch to fix the build on aarch64, you'll apply the patch
(unless it's broken of course).


> 3. feh and optipng are relatively simple to
>   test, and I use them frequently, but with
>   busybox there is a huge number of things
>   to test; personally I only use a subset
>   in some scripts.  Any solutions for this
>   problem?  (e.g. a way for multiple test
>   users to try it out before publishing it
>   to SBo proper).

You can put your modified script somewhere public and post on the
mailing list about it, ask for people to help you test it.

> 4. If my request to take over the packages is
>   granted, do I wait until next upstream
>   update?  Or do I push an update to change
>   the maintainer immediately?

Go ahead and send an update to change the maintainer info
immediately. You could also make other changes at the same time
(version update, or fix a bug).

> 5. If I don't want to use GitHub or GitLab,
>   what other options do I have?  Can I send
>   git patch emails somewhere?  Or is the web
>   submission form the only alternative?

I'm not in charge of the github/gitlab stuff (I don't even have
accounts on either service), but so far as I know, the choices are
github, gitlab, or the web submission form. I don't think we ever pull
from any other git repos. If I'm wrong, someone (Willy) will probably
correct me.

There are a couple of tools that automate the process of using the
web submission form, which would be better than doing it manuall with
a browser. One is called "sbosubmit".

> Thank you all for your work on SlackBuilds.

Thank you for your interest. Hope this answers some of your questions
in a useful way. The Maintainer FAQ is still a work in progress, and
your email has motivated me to start working on it again.