On 22/06/2021 10:48, Caleb Maclennan via aur-general wrote:
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.
That's the opposite case, not precedence. The official repos covers
*previous* incompatible versions. If the repos had audacity3 and the AUR
uploaded audacity2 we wouldn't talk about this.
I'll move down some paragraphs since my time is limited.
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.
Suggesting to users a deletion request is invalid counts as
"unilaterally jumping and doing them". Proposing things for discussion
would be opening a topic on aur-general.
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.
The way I see it, adding some kind of time-related exception rules is
pretty complicated and will soon end up in everyone thinking they
qualify for an exception. That doesn't help with an already high amount
of stale AUR requests out there.
Now if people want to take up some package in AUR because "nobody is
responding on community", it's again fine to start a discussion. The
maintainer might even drop it to AUR. In fact, maintainers have dropped
"unpackageable" packages (e.g. freeCAD) to AUR before.
So really, it's a shame nobody actually started a discussion, submitted
packages going against the submission guidelines instead, and then
argued the submission guidelines are actually not right.
Alad
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
