[aur-general] Another removal request
Hello, Can the following package be removed please: https://aur.archlinux.org/packages/icewm-testing/ It's basically just an out of date duplicate of the icewm package in the official repos. It uses exactly the same sourceforge.net sources as the official package, the only difference being that it's a version out of date. It's also orphaned, hasn't been updated since 2011 and has just 6 votes. Regards
You're as keen as I am :)
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.
- Steven
On 1 June 2014 21:44, Charles Bos
Hello,
Can the following package be removed please: https://aur.archlinux.org/packages/icewm-testing/
It's basically just an out of date duplicate of the icewm package in the official repos. It uses exactly the same sourceforge.net sources as the official package, the only difference being that it's a version out of date. It's also orphaned, hasn't been updated since 2011 and has just 6 votes.
Regards
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. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5
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? Gesh
On Mon, Jun 2, 2014 at 4:31 PM, Gesh
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.
Hmm. One appropriate repsonse to the flag could be "ban user from flagging for action"... Add a mandatory message textarea, and it's almost the same as today, except. Well, there's that one point where the email could be sent once, at high traffic even several times a day, remove noise on this ML and collect requests all over different users which the TUs then can consider one by one.
* 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.
Integrate the deletion request/request for update/adoption into that interface, and we can measure the 2 weeks in code, and then drop the request automatically (if it's still relevant) without always having to remind people about it. How do we know it's still relevant? Well. That would require human interaction, which is bad, because the emails get delivered and the TUs would not have to ask back if that request was sitll relevant. Although, there could be a 13-21 day reactivation time frame in which the requester could check his email and remind the system to actually drop the request.
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? Gesh
That is, I am going to guess there should be a long-standing flyspray / feature request about this, but I'm too lazy to look it up. cheers! mar77i
participants (5)
-
Charles Bos
-
Gesh
-
Johannes Löthberg
-
Martti Kühne
-
Steven Honeyman