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