[aur-general] Another removal request

Gesh gesh at gesh.uni.cx
Mon Jun 2 10:31:00 EDT 2014

On 2014-06-02 00:20, Johannes Löthberg wrote:
> On 01/06, Steven Honeyman wrote:
>> What would be useful is a "Flag for deletion" button on the AUR. It
>> could (for example) only show up once a package has been flagged as
>> "out of date" for a month, and require a short reason why. It'd save
>> all these poor devs getting cluttered mailing lists, and would
>> definitely clean up the number of useless/obsolete/broken packages as
>> more people would be reporting them.
> Having to send removal emails to the ML serves as a papertrail of what
> happened to old packages.
Forgive me if this is a stupid question, but wouldn't a design like the
following give you this paper trail?
* Add a "flag for deletion/merge/orphan" button on the AUR - possibly
   subject to restrictions requiring the package to have been marked out
   of date for a while, as well as requiring the specification of the
   package/user to replace the current package/maintainer.
* This button would send out an automated email to the maintainer, who
   would get the opportunity to respond.
* If no response has been received, the package is hidden from AUR
   results and added to some page on the AUR visible only to TUs.
   Alternatively, the package's AUR page gets marked with a prominent
   warning that it has been flagged for deletion/merge/orphan and might
   stop being available. It would still appear in that TU-only page.
* The TUs get to choose the appropriate response to the flag.
* Every day, a flag report gets sent to the ML, listing the packages
   for which the maintainer hasn't responded to emails regarding the
   flag, as well as the changes made to the AUR by TUs.
This reduces the administrative burden users have to go through in order
to request the deletion/merge/orphan of a package, as well as making it
easier for the TUs to see what has been requested. It would unclutter
the ML, and would still provide a paper trail. As far as I can see, it
would be a net win for all users.
However, to paraphrase Schneier's Law, anyone can design a system of
which he can't see the bugs. So, can anyone point out the problems this
system would have?

More information about the aur-general mailing list