On Wed, Aug 12, 2015 at 11:05 AM, Lukas Fleischer <lfleischer@archlinux.org> wrote:
Wikipedia defines orphan as
[...] a child whose parents are dead or have abandoned them permanently
...but new parents may want to adopt them, if given the opportunity. Deleting *long-time* orphaned packages may increase the overall quality of the AUR, but aggressively deleting them within mere hours or days (before new maintainers had a chance to find them), will have the opposite effect - because it encourages the old maintainers to hang on to packages pro-forma even when they don't actually maintain them anymore, leading to more stale packages in the AUR and no way to easily identify them. Orphaning helps smooth the process of getting a package in the hands of an active maintainer (and thus ensuring best package quality), because it: - It allows potential maintainers to discover them (through AUR helpers which show orphaned status, or by explicitly searching for orphans in the web interface - there's even a special button for it). - It encourages potential maintainers to adopt the package, by making it as painless as possible (one mouse click) rather than confronting them with a situation (inactive maintainer) where adoption might take an unknown amount of time and stress (and thus many won't bother).
So maybe we need to improve the way changing maintainership works. Having a "Give up for adoption" button (that keeps the current maintainer while allowing anybody to adopt the package) in addition to "Disown" is one possibility.
What is the point of the "disown" button then, if it does the same thing as "request for deletion"? There are two possible things at play here that a maintainer might want to do: 1) "I want the package to be deleted." 2) "I want a new maintainer to find this package (e.g. because I don't use this software anymore, but other users and packages still depend on it)." Until now, we could use "request for deletion" for (1), and "disown" for (2). Now that you're making "disown" work like "request for deletion", we have two redundant mechanisms for (1), and none for (2). Adding a third mechanism like you suggest is a possibility, but why not just have one for each like we did until now?