[aur-general] Deletion of orphaned packages on AUR4

[Sam S.]

On Wed, Aug 12, 2015 at 11:05 AM, Lukas Fleischer
<lfleischer at 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?