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 <[email protected]> To: Eli Schwartz <[email protected]>
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
signature.asc
Description: OpenPGP digital signature
