[Slackbuilds-users] Maybe Taking Over Some Packages

[Charadon]

Do you have a link to that sbosubmit tool? That sounds very handy!


-----Original Message-----
From: B. Watson [mailto:urchlay at slackware.uk]
Sent: Sunday, September 15, 2024 03:55 PM -04
To: lumin--- via SlackBuilds-users
Cc: lumin at etherlight.link
Subject: Re: [Slackbuilds-users] Maybe Taking Over Some Packages



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.
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users at slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/