Plain copy of reply -------- Forwarded Message -------- Subject: Re: [PATCH] Make delete and merge links create an auto-accepted request Date: Sun, 23 Dec 2018 23:19:47 +0100 From: Johannes Löthberg <johannes@kyriasis.com> To: Eli Schwartz <eschwartz@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 notifications.

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 other changes.

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 community".

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 these actions.

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 simplistically either. -- Sincerely, Johannes Löthberg