Forwarded from mailto:aur-general@lists.archlinux.org, as it doesn't appear to have sent there.
============ Forwarded message ============ From: Hunter Wittenborn hunter@hunterwittenborn.com To: "aur-requests"aur-requests@lists.archlinux.org Date: Wed, 15 Dec 2021 23:28:09 -0600 Subject: Why were my 'makedeb-beta' and 'makedeb-alpha' packages deleted? ============ Forwarded message ============
Hi,
I just received some emails about an hour ago that my 'makedeb-beta' and 'makedeb-alpha' packages were deleted off of the AUR because they were duplicates of 'makedeb' [1] [2]. I'm a bit confused on how exactly they're "duplicates" of makedeb though, as they're literally the beta and alpha releases for makedeb, the lattermost being the stable release.
The only other hypothesis I'd have is that the underlying program is the same, but these are all different releases, and they're all being published so users can use whichever channel they chose. My packages also aren't the only ones following a multi-channel packaging system on the AUR, so I'm not really sure why my packages got flagged like this in particular.
Could I get an explanation for all of this? I'm quite confused on how I could have messed up - recloning the PKGBUILDs for 'makedeb-beta' and 'makedeb-alpha' on my local system is also still clearly showing the differences between the three packages.
[1]: https://lists.archlinux.org/pipermail/aur-requests/2021-December/063223.html
[2]: https://lists.archlinux.org/pipermail/aur-requests/2021-December/063222.html
---
Hunter Wittenborn
mailto:hunter@hunterwittenborn.com
On 2021-12-16 16:58, Hunter Wittenborn via aur-general wrote:
I just received some emails about an hour ago that my 'makedeb-beta' and 'makedeb-alpha' packages were deleted off of the AUR because they were duplicates of 'makedeb' [1] [2]. I'm a bit confused on how exactly they're "duplicates" of makedeb though, as they're literally the beta and alpha releases for makedeb, the lattermost being the stable release.
The only other hypothesis I'd have is that the underlying program is the same, but these are all different releases, and they're all being published so users can use whichever channel they chose. My packages also aren't the only ones following a multi-channel packaging system on the AUR, so I'm not really sure why my packages got flagged like this in particular.
Could I get an explanation for all of this? I'm quite confused on how I could have messed up - recloning the PKGBUILDs for 'makedeb-beta' and 'makedeb-alpha' on my local system is also still clearly showing the differences between the three packages.
Hi, Hunter! Thanks for the email
I must admit, this was probably a poor decision on my part. I should have rejected those requests. I could go into the specifics of my thought process but ultimately it was a gaffe on my part. I'm sorry!
I've reinstated the packages, so please do claim them from the orphanage.
Thanks for the pushback, and I'm sorry again.
That's all good, as long as I'm able to keep using the packages I should be fine.
Could I ask why those requests were even sent in the first place though? I don't want to linger out the drama, but I don't see much of what could've been mistaken if the PKGBUILD's weren't checked before actually sending in the requests. It looks like the requests were submitted by grawlinson and not you, so I'm just a bit curious about what he was thinking.
---
Hunter Wittenborn
mailto:hunter@hunterwittenborn.com
https://www.hunterwittenborn.com
https://github.com/hwittenborn
---- On Thu, 16 Dec 2021 17:42:26 -0600 Brett Cornwall via aur-general aur-general@lists.archlinux.org wrote ----
On 2021-12-16 16:58, Hunter Wittenborn via aur-general wrote:
I just received some emails about an hour ago that my 'makedeb-beta' and 'makedeb-alpha' packages were deleted off of the AUR because they were duplicates of 'makedeb' [1] [2]. I'm a bit confused on how exactly they're "duplicates" of makedeb though, as they're literally the beta and alpha releases for makedeb, the lattermost being the stable release.
The only other hypothesis I'd have is that the underlying program is the same, but these are all different releases, and they're all being published so users can use whichever channel they chose. My packages also aren't the only ones following a multi-channel packaging system on the AUR, so I'm not really sure why my packages got flagged like this in particular.
Could I get an explanation for all of this? I'm quite confused on how I could have messed up - recloning the PKGBUILDs for 'makedeb-beta' and 'makedeb-alpha' on my local system is also still clearly showing the differences between the three packages.
Hi, Hunter! Thanks for the email
I must admit, this was probably a poor decision on my part. I should have rejected those requests. I could go into the specifics of my thought process but ultimately it was a gaffe on my part. I'm sorry!
I've reinstated the packages, so please do claim them from the orphanage.
Thanks for the pushback, and I'm sorry again.
I can't speak for grawlinson, but I did want to bring up a point that, off the top of my head, might be a reason for deletion requests.
In software, `alpha` is used for a release before a `beta` or a straight up release. `beta` is used in the same way, but is more tightly coupled directly behind an official release.
Most of the time, projects do the following: 1. Release alpha, get testing done. 2. Release beta, obsolete alpha, get testing done. 3. Release for real, obsolete alpha/beta which was previously released.
So, normally, alpha and beta packages are just earlier versions of their non-alpha or non-beta counterparts. What is the exact point of your `-alpha` and `-beta` packages if `makedeb` exists and can be used?
Best, Kevin
It's the same reason packages like 'google-chrome-beta' [1] and 'google-chrome-dev' [2] exist, it's just so users can use more cutting-edge releases if they so choose. I just use '-beta' and '-alpha' as my version of the '-beta' and '-dev' versions, they're all part of my actual program's Git repository, they're just named such to describe the nature of the release.
I could see the possible confusion with it being thought that these were prerelease-like versions that are just temporary codenames that'll be obsoleted by new ones in the future, but again, this could easily have been seen by looking at the PKGBUILDs, and equally as important at the upstream repository [3].
Again, I'm not trying to create a bunch of drama, I'm just really wanting to know how this deletion could have even been submitted if everything was properly checked, as this becomes quite an issue when I'm wanting these packages to be reliably available to end users.
[1]: https://aur.archlinux.org/packages/google-chrome-beta/
[2]: https://aur.archlinux.org/packages/google-chrome-dev/
[3]: https://github.com/makedeb/makedeb/branches
---
Hunter Wittenborn
mailto:hunter@hunterwittenborn.com
https://www.hunterwittenborn.com
https://github.com/hwittenborn
---- On Thu, 16 Dec 2021 18:52:50 -0600 Kevin Morris via aur-general aur-general@lists.archlinux.org wrote ----
I can't speak for grawlinson, but I did want to bring up a point that, off the top of my head, might be a reason for deletion requests.
In software, `alpha` is used for a release before a `beta` or a straight up release. `beta` is used in the same way, but is more tightly coupled directly behind an official release.
Most of the time, projects do the following: 1. Release alpha, get testing done. 2. Release beta, obsolete alpha, get testing done. 3. Release for real, obsolete alpha/beta which was previously released.
So, normally, alpha and beta packages are just earlier versions of their non-alpha or non-beta counterparts. What is the exact point of your `-alpha` and `-beta` packages if `makedeb` exists and can be used?
Best, Kevin
Mistakes are made. As was already done, deleted packages can be restored via the git interface. I understand your difference, I was just explaining why one may have made that deletion request.
Of course, the user who made the request and the TU who accepted it become aware that this was a mistake, and they'll remember it for the future.
The platform is not automatically moderated at all. It is generally easier for a maintainer to reach out for a request being problematic than trying to reach out to every maintainer who owns packages that requests are made for; which would absolutely slow down these actions behind a wall of logistics.
The last point may be nice for an org who wishes that their packages are never touched, but, this is a user-run platform, and with that comes the fact that TUs need to sometimes make decisions without input from owners of the packages.
It is what it is, and that's most likely how it happened. It's not the end of the world, as you know, since your package was already reinstated back to what it was before the deletion occurred.
Please consider this a minor inconvenience. It's not something that dramatically changes anything about the topic in question, and it does not affect your project in a very bad way overall -- it was a mishap, and mishaps happen.
Mistakes are OK. What isn't okay is then returning and arguing that the mistake wasn't a mistake -- that is not what's happening.
Best, Kevin
On Thu, Dec 16, 2021 at 08:15:52PM -0600, Hunter Wittenborn via aur-general wrote:
It's the same reason packages like 'google-chrome-beta' [1] and 'google-chrome-dev' [2] exist, it's just so users can use more cutting-edge releases if they so choose. I just use '-beta' and '-alpha' as my version of the '-beta' and '-dev' versions, they're all part of my actual program's Git repository, they're just named such to describe the nature of the release.
I could see the possible confusion with it being thought that these were prerelease-like versions that are just temporary codenames that'll be obsoleted by new ones in the future, but again, this could easily have been seen by looking at the PKGBUILDs, and equally as important at the upstream repository [3].
Again, I'm not trying to create a bunch of drama, I'm just really wanting to know how this deletion could have even been submitted if everything was properly checked, as this becomes quite an issue when I'm wanting these packages to be reliably available to end users.
Hunter Wittenborn
mailto:hunter@hunterwittenborn.com
https://www.hunterwittenborn.com
https://github.com/hwittenborn
---- On Thu, 16 Dec 2021 18:52:50 -0600 Kevin Morris via aur-general aur-general@lists.archlinux.org wrote ----
I can't speak for grawlinson, but I did want to bring up a point that, off the top of my head, might be a reason for deletion requests.
In software, `alpha` is used for a release before a `beta` or a straight up release. `beta` is used in the same way, but is more tightly coupled directly behind an official release.
Most of the time, projects do the following:
- Release alpha, get testing done.
- Release beta, obsolete alpha, get testing done.
- Release for real, obsolete alpha/beta which was previously released.
So, normally, alpha and beta packages are just earlier versions of their non-alpha or non-beta counterparts. What is the exact point of your `-alpha` and `-beta` packages if `makedeb` exists and can be used?
Best, Kevin
-- Kevin Morris Software Developer
Identities:
- kevr @ Libera
Why were my packages deleted again? They just got deleted by grawlinson again - could you please explain what exactly is the problem with my packages?
If users really want to run the latest, they can run a `-git` version.
Again, I have multiple releases, and I'd like users to be able to choose between them. None of the three releases are meant to be like '-git' packages, as they're all versioned, and the only one that would necessarily be somewhat like '-git' would be 'makedeb-alpha', but my current system, again, has these all versioned, and I'd prefer it be kept in the same manner as makedeb is being maintained across other platforms.
---
Hunter Wittenborn
mailto:hunter@hunterwittenborn.com
https://www.hunterwittenborn.com
https://github.com/hwittenborn
---- On Thu, 16 Dec 2021 21:23:11 -0600 Kevin Morris via aur-general aur-general@lists.archlinux.org wrote ----
Mistakes are made. As was already done, deleted packages can be restored via the git interface. I understand your difference, I was just explaining why one may have made that deletion request.
Of course, the user who made the request and the TU who accepted it become aware that this was a mistake, and they'll remember it for the future.
The platform is not automatically moderated at all. It is generally easier for a maintainer to reach out for a request being problematic than trying to reach out to every maintainer who owns packages that requests are made for; which would absolutely slow down these actions behind a wall of logistics.
The last point may be nice for an org who wishes that their packages are never touched, but, this is a user-run platform, and with that comes the fact that TUs need to sometimes make decisions without input from owners of the packages.
It is what it is, and that's most likely how it happened. It's not the end of the world, as you know, since your package was already reinstated back to what it was before the deletion occurred.
Please consider this a minor inconvenience. It's not something that dramatically changes anything about the topic in question, and it does not affect your project in a very bad way overall -- it was a mishap, and mishaps happen.
Mistakes are OK. What isn't okay is then returning and arguing that the mistake wasn't a mistake -- that is not what's happening.
Best, Kevin
On Thu, Dec 16, 2021 at 08:15:52PM -0600, Hunter Wittenborn via aur-general wrote:
It's the same reason packages like 'google-chrome-beta' [1] and 'google-chrome-dev' [2] exist, it's just so users can use more cutting-edge releases if they so choose. I just use '-beta' and '-alpha' as my version of the '-beta' and '-dev' versions, they're all part of my actual program's Git repository, they're just named such to describe the nature of the release.
I could see the possible confusion with it being thought that these were prerelease-like versions that are just temporary codenames that'll be obsoleted by new ones in the future, but again, this could easily have been seen by looking at the PKGBUILDs, and equally as important at the upstream repository [3].
Again, I'm not trying to create a bunch of drama, I'm just really wanting to know how this deletion could have even been submitted if everything was properly checked, as this becomes quite an issue when I'm wanting these packages to be reliably available to end users.
Hunter Wittenborn
mailto:mailto:hunter@hunterwittenborn.com
https://www.hunterwittenborn.com
https://github.com/hwittenborn
---- On Thu, 16 Dec 2021 18:52:50 -0600 Kevin Morris via aur-general mailto:aur-general@lists.archlinux.org wrote ----
I can't speak for grawlinson, but I did want to bring up a point that, off the top of my head, might be a reason for deletion requests.
In software, `alpha` is used for a release before a `beta` or a straight up release. `beta` is used in the same way, but is more tightly coupled directly behind an official release.
Most of the time, projects do the following:
- Release alpha, get testing done.
- Release beta, obsolete alpha, get testing done.
- Release for real, obsolete alpha/beta which was previously released.
So, normally, alpha and beta packages are just earlier versions of their non-alpha or non-beta counterparts. What is the exact point of your `-alpha` and `-beta` packages if `makedeb` exists and can be used?
Best, Kevin
-- Kevin Morris Software Developer
Identities:
- kevr @ Libera
On 21-12-17 15:43, Hunter Wittenborn wrote:
Why were my packages deleted again? They just got deleted by grawlinson again - could you please explain what exactly is the problem with my packages?
If users really want to run the latest, they can run a `-git` version.
Again, I have multiple releases, and I'd like users to be able to choose between them. None of the three releases are meant to be like '-git' packages, as they're all versioned, and the only one that would necessarily be somewhat like '-git' would be 'makedeb-alpha', but my current system, again, has these all versioned, and I'd prefer it be kept in the same manner as makedeb is being maintained across other platforms.
vercmp(8) has this to say about version strings:
Version comparison operates as follows:
Alphanumeric: 1.0a < 1.0b < 1.0beta < 1.0p < 1.0pre < 1.0rc < 1.0 < 1.0.a < 1.0.1
Numeric: 1 < 1.0 < 1.1 < 1.1.1 < 1.2 < 2.0 < 3.0.0
Additionally, let's look at Firefox packages:
extra/firefox 95.0.1-1 community/firefox-developer-edition 96.0b6-1 aur/firefox-nightly 97.0a1.20211208-1
The version numbers have clear separation, and it's easy to spot which are alpha/beta releases.
With makedeb, it's all the same:
makedeb 8.8.8 makedeb-alpha 8.8.8 makedeb-beta 8.8.8
That's just confusing, and there's no clear separation between all of the packages. If you really want to keep them 'separate', I suggest fixing your versioning.
-- George Rawlinson
aur-general@lists.archlinux.org