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