Fwd: [PATCH] Make delete and merge links create an auto-accepted request
eschwartz at archlinux.org
Sun Dec 23 23:10:42 UTC 2018
Plain copy of reply
-------- Forwarded Message --------
Subject: Re: [PATCH] Make delete and merge links create an auto-accepted
Date: Sun, 23 Dec 2018 23:19:47 +0100
From: Johannes Löthberg <johannes at kyriasis.com>
To: Eli Schwartz <eschwartz at archlinux.org>
Excerpts from Eli Schwartz's message of December 23, 2018 22:58:
> On 12/23/18 4:14 PM, Johannes Löthberg wrote:
>> This lets us have a better paper-trail over what happens in the AUR.
> I'm opposed to this change.
> The purpose of those links is arguably to do things in exceptional
> circumstances. There are cases where an auto-accepted request is simply
> uninteresting information. e.g., the following cases:
> - user submits deletion request, Eli Schwartz uses "close" instead of
> "accept", with the message "merged instead". Do we really need
> additional notifications here?
I think that is a better portrayal of reality, yes. I do not see there
being any really justified reasons for anyone being able to delete a
package without a request.
> - deletion of spam packages
I believe that that is still just as interesting to have in the history.
We've already had quite a few cases where there was confusion as to what
happened to a package just because it was deleted directly.
> Moreover, the current proposal is simply inferior in every possible way
> compared to simply submitting a request, then accepting it. That way you
> get to leave a message saying why it happened... I would simply never
> ever use the delete/merge links if I actually wanted to send out
It's hardly inferior, it's just different. There are obviously TUs that
currently use them but don't want to leave a message, this still lets
them do exactly that. And even if we would not actually create an
auto-accepted request for it, I believe that it is wrong to not always
send out at least a notification when a package is deleted. Having an
actual request created just makes it easier to see them along with all
> On top of this, where is the notification for orphaning packages against
> the will of the maintainer?
That is fundamentally a different change and feature that has nothing to
do with this patch.
> It's basically accepted practice regardless that when TUs adopt a
> package into community, they submit a deletion request and then accept
> it. This will traditionally include the high-content comment "moved to
Sure. Except for when they don't.
> The current patchset was proposed in response to one TU on IRC,
Incorrect. I have been planning on doing this for months, and talked to
Lukas about it months ago as well.
> who feels strongly about the goal of said paper trail and desired to have
> the entire feature removed from aurweb altogether. I propose instead
> that we follow my recommendation to document on the wiki at
> https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines that
> TUs should submit a deletion request *with the relevant comment* rather
> than deleting the package.
> I see no reason to modify the emergency override tools.
Before you get to call them "emergency override tools" we're going to
both need to *clearly* label them as such, and preferably move them to a
separate section. As it is they are, and will continue to be, "just
tools," especially since they are the easiest option for performing
> Note: regarding the person who suggested on IRC that the links should be
> removed, the orphan link in particular is utterly crucial to remain,
> since aurweb includes a feature to accept an orphan request early by
> leaving a comment and *not* actually orphaning the package. This
> requires the TU to manually use the orphan link. If orphan requests were
> given fair treatment with the other two request types, this would result
> in a second notification every time it was used.
> More generally, if you wish to leave a comment in the acceptance
> notification, you must use the same comment form followed by manual
> followup when closing a deletion or merge request as well (although
> those are not locked for the duration of a 14-day grace period).
But then again, there is no reason to actually implement it that
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the aur-dev