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

[alad]

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