Fwd: [PATCH] Make delete and merge links create an auto-accepted request

[Eli Schwartz]

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 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
> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-dev/attachments/20181223/e8c5b924/attachment-0001.asc>