[aur-general] AUR - 'kernel26' search results

[Heiko Baums]

Am 21.09.2010 02:22, schrieb Ulf Winkelvos:
> i also think automation is not the way to go. but the aur could be a lot
> more userfriendly. 3 things come to my mind:
> 
> 1) removal request button - for the mainatiner only.
This couldn't hurt if there's a text field for giving reasons why the
package shall be removed. But I don't see a benefit. It's not more work
to write a short e-mail to the mailing list. The e-mail actually has
more advantages because with such a button you can send a removal
request for only one package and you need to send a separate removal
request for every package. In an e-mail you can add package names and
the links to them for several packages at once.

So I'd prefer not having such a button.

> 2) mark as dublicate button - needs 3 (? to prevent abuse) votes from
> different users
Why do you need votes for reporting duplicates? A package is either a
duplicate or it is not. This is not a democratic question. And like the
removal request button I don't see an advantage to a simple e-mail.

> 3) orphran request button - needs 1 vote or a percentage of total usage
> votes - is only available when the package is flaged out of date for
> 7-14 days.
This is not a democratic question, too. Read my first e-mail in this
thread. This definitely will be abused by impatient people who don't
want to ask if there's a reason why a package is not updated. And 7 to
14 days is far too short (e.g. holidays, bugs in the new version, etc.).

And who shall adopt this package? Most of those impatient users
certainly don't really want to adopt and maintain this package,

And I bet that no one of those voters will try to contact the maintainer
before voting.

So such an orphan request button *must not* be implemented.

The way it is currently is the way to go. The user who wants to adopt a
package and who probably already has an updated PKGBUILD first must try
to contact the maintainer by AUR comment and by private e-mail, must
wait at least two or three weeks for respons, must probably try to
contact the maintainer a second time and then send an orphan request to
the mailing list, so that a TU can first review this request.

This is the only way this can be done. But definitely not by voting in
the AUR.

> all requests are send to the mailing list. So TUs still have full
> control, but ist pretty handy for users that are not on the ml.
So why then implement such buttons? Why not send an e-mail directly to
the mailing list? See the advantages above. And some of those request
*must not* get a voting feature because they are just ineligible.

> Another thing: Multiple maintainers would be realy nice... although
> anybody should put more thought into that, as it could easily become
> pretty messy.
Can be nice. But a second maintainer may only be added by the first
maintainer. Otherwise this can easily be abused by those impatient
people. See above. In case of packages on which are working to people
together who are in contact with each other regarding this package this
could make it a bit easier. But in such a case only the maintainer of
the package may add the second maintainer.

Heiko