[aur-general] TU application for Caleb, aka alerque

[Caleb Maclennan]

On 2021-06-21 18:58, Eli Schwartz via aur-general wrote:
> It appears you've been agitating on the AUR comments for some 
> duplicates
> of the community/audacity package:

Not "some duplicates", just one duplicate. ;-)

> Given the purpose of the Trusted Users to whom you are applying, is not
> just to publish packages in [community], but also to moderate and keep
> order in the AUR, I find it extremely relevant that halfway through an
> otherwise decent application you are advocating for this sort of thing.

But yes this is quite relevant to TU operations so let's dig in.

First I'm quite aware of the no-duplicates rule, and I think it makes 
perfect
sense about 99% of the time. That being said not all upstream software
projects are neat and tidy and not all Arch package situations are 
equal.
I do think there is a 1% grey area and that evaluating specifics of
a situation will turn up cases where Arch's "pragmatism" should trump 
100%
ideological by-the-books rule application.

1. There significant precedent in Arch official repos for duplicate
    packages if they cover incompatible major versions. PHP, Node,
    Electron, Python, Lua, GTK, and so on. Mostly RTEs and libraries, but
    apps aren't unheard of either. Sometimes it just makes sense to keep
    several major versions available so people can use what works for 
them
    until the ecosystem moves on far enough that dropping the old ones
    makes sense.

2. The AUR has an even more significant precedent for this. It's quite
    common and largely accepted to find what you are labeling as
    a "duplicate" if they serve some measurable purpose. Duplicates for 
the
    same of duplicates of course are not allowed. Duplicates for recently
    out of date things isn't allowed. Duplicates just to tweak some
    preferences that either could be set other ways or are not broadly
    relevant is not allowed. There are quite a few more iterations of 
this
    that are just not allowed.

    But some cases don't fit any of those situations. There are currently
    over 3k packages in the AUR that end in a number. A small chunk of
    these are just projects that end in a number (e.g. x11, v8). Another
    chunk are useless obsolete cruft that should be deleted. But
    a significant number of those are legitimate major-version packages
    older or newer than arch repos that serve substantive purposes.

    - Compile time options that make for a significantly different
	 experience are sometimes allowed as AUR packages. Generally Arch repo
	 packages enable all options by default, but there are a handful of
	 cases where that is not the case and something keeps the Arch repo
	 packages in a limited function mode. In some of these cases it is
	 allowed to have AUR packages that enable the feature and let users
	 choose if they want to run that over the official package.

    - Major versions with backwards incompatible changes where the 
version
	 bump is being held back in Arch repos are often allowed in the AUR.
	 The reverse is also common, when the Arch repos get a major version
	 bump that makes backwards comparability a problem, running an old
	 version out of the AUR is the common solution. There are no less that
	 23 packages for old versions of ICU. I'm guessing half of them are now
	 useless cruft, but I wouldn't say they should all be nuked without
	 reviewing their utility. 14 more for electron (mostly -bin variants),
	 47 for the Android SDK, and so on.

    Yes I realize that many of these are also designed to be used in
    parallel. Android SDK for example, as well as Electron runtimes. This
    is not the case for all packages, nor can it be realistically. One
    example is exim. You can't realistically set up packages to run
    multiple instances of exim, but there are good reasons to package it 
in
    "duplicate" to the community package. The community package is 
current
    pretty current, but historically there have been reasons it got held
    back and patched instead of updated. Allowing AUR packages to take 
the
    other road is something I think should be legitimate. If tomorrow an
    exim 5.0 comes out with some backwards incompatible bits that
    required libraries or something that broke some systems, I would 
expect
    the community repo to hold onto 4.x for a *little* while, and an AUR
    package for exim5 to crop up in the interim. Later as the migration
    dust settles and the path to update is more clear for more people,
    I would expect Arch to stay pretty current and update as soon as
    feasible, but when it does I would fully expect the exim5 package to 
go
    away from the AUR and an exim4 package to take its place for people
    that can't be bothered to migrate for a while but have production
    servers they want to otherwise keep patched. Using the same example,
    Arch has been ignoring the new DMARC features in exim for over a year
    now. Not enabling them while they were experimental made sense, but
    they have been stable since Dec 2019 and Arch has been ignoring the
    relevant bug report / feature request. I think it would be totally 
fair
    gaim if somebody wanted to make an AUR package for exim-dmarc that
    enables the feature. Yes this is a "duplicate", but not all 
duplicates
    are just duplicates.

Speaking of duplicates and content moderation, it might be relevant to
note that I was a moderator on 2 different stack exchange sites, both
pro-tempera and then elected. Anybody that has hung out on SE sites 
knows
the issue of duplicate question closure is a sensitive topic and 
moderator
decisions are often contested. In 8 years of being a moderator there I 
was
challenged many times, but I always took the time to explain myself. My
explanations almost never failed to be the highest votes meta answers to
controversial decisions.

https://christianity.meta.stackexchange.com/users/30/caleb?tab=summary

I also have a long track record of proposing things for discussion there
*before* unilaterally jumping in and doing them. I would expect to 
follow
the same modus operendi as a TU. Many actions as a content moderator are
just janitorial and you can follow the rules and plow through them. The
expertise comes in spotting the cases where extra care is required and
either special handling is needed or discussion needs to be started to
handle them in a way that is more broadly satisfactory than a spur of 
the
moment decision. I'll let my track record speak for itself.

Now about Audacity in particular....

As background, many years ago when working as an audio engineer I used 
to
use it in production nearly full time. I'm quite familiar with it's past
and the weird development practices upstream (such as forked toolkit
versions). I am no longer in that field and only occasionally dabble 
with
it for hobby purposes.

A year ago when the last minor version bump to the 2.x series came out, 
by
chance I happened to be hit with one of the bugs that had been fixed
upstream. I don't think I was the flagger for that update, but I came
along right about that time hoping for an update. When there was none,
I tried to build it myself. I quickly realized what a fiasco that was
because the minor version didn't build cleanly at the time without
changes to the packaging and other arch libraries. At the time the OOD
flag was within a couple weeks old, so I abandoned the project and 
solved
my audio issue another way. Later I switched to the -git package that 
got
updated to resolve the build issues.

Having a minor version bump stay out of date for a while shouldn't be
a huge deal, but having one with known bugs that block some production
workflows stay out of date for over a year is egregious. That in itself
may not be a good reason to allow duplicates on the AUR, but I do think
the timeline is relevant. Duplicates in the first couple weeks should be
a total no-no. On the AUR 2 weeks is when you can start filing orphan
requests. Something like that should probably be implemented for 
community
packages too. Maybe not 2 weeks, but if they are out of date for 2 
months
and nobody is even responding the flags or bug reports that starts to 
make
the AUR a *better* place that [community]. That's kinda backwards, no? 
If
things stay out of date for two long I think there should be some
procedure for either getting other maintainers involved or demoting them
to the AUR where interested parties could keep them more up to date.

So far those are just discussion points, not something I would feel free
to enforce as a TU, just opinions I have and would root for eventual
guideline updates.

Audacity v3 is a bit different. As a major version release being handled
by a new upstream developer (the project changed hands) with new release
procedures and development cycle, and most notable BACKWARDS 
INCOMPATIBLE
bits that break people's workflow by default, I think it should be fair
game to post an audacity3 package to the AUR for adventurous souls that
know they want to switch. The maintainer of the [community] package 
should
get the minor version bump at least figured out post-haste. At their
discretion they can update to the v3 release whenever they think it
reasonable. I would argue for sooner rather than later, but I don't know
what complications that might have for wxGTK toolkit packaging, so I am
not casting judgement on that. When they to get v3 packaged in the 
repos,
I would expect the audacity3 package to be deleted, and if people feel 
the
need for it an audacity2 package could be posted to the AUR for people
that need the old version for their workflow. When that eventually 
becomes
irrelevant it should be cleaned up and removed.

Does that make sense? Even if you don't agree with what I‌ think should
have happened with the audacity3 package do you have ongoing concerns
about how I would approach controversial decisions? In cases like this I
think interacting with other potential decision makes is at least as
important as the final decision. We can't just play tug of war posting
and deleting packages. I'm willing to take the topics where I don't
necessarily agree with other TU's here for discussion before just
implementing them. And honestly I've been using Arch on a lot of systems
for a lot of years and don't have significant methodology disagreements
so I am not anticipating conflict. I use Arch and the AUR because I‌ 
think
it is a good balance of concerns and useful ecosystem pattern.

Regards,
Caleb