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

[Thorsten Töpper]

On Mon, 20 Sep 2010 22:16:27 +0200
Heiko Baums <lists at baums-on-web.de> wrote:
> Am 20.09.2010 21:02, schrieb Det:
> > Hey, that's great! Stuff like 'online' PKGBUILD editor, auto clean
> > of AUR from obsolete/old packages (e.g. over year old packages that
> > don't have many votes, have no maintainers and have been flagged
> > out of date (if even that)), a little faster updation of the
> > downloadable package tarballs after a change has done to the
> > package, some well designed *vote orphan* button that'd reduce the
> > "please orphan" requests to TUs and other stuff like that? It'd be
> > _very_ nice, if that stuff got implemented!
> 
> I don't think that this would be so nice. This would mean less control
> by the maintainers and TUs. I think requesting such things on the
> mailing list would be much better, because then TUs and other people
> get to know about this issue, it can be better reviewed and it can be
> better discussed on the mailing list if necessary than on the AUR
> comments etc.
> 
> And how do you know if a package which is more than a year old, has
> only a few votes and no maintainer doesn't work and is not usable
> anymore?
> 
> That a package has no maintainer just says that the previous
> maintainer doesn't want to maintain it anymore because he isn't using
> this package anymore, because he switched the distro or something
> like that.
> 
> If a package has only a few votes can mean that it is a special tool
> which is not used by many people or it is not well known, which
> doesn't mean that it is bad.
> 
> If a package was not updated for more than a year can just mean that
> there's no need for an update because it's just working and nothing
> has to be changed.
> 
> And these are things which need to be checked by a human.
> 
> An online PKGBUILD editor can be but is not necessarily good because
> the maintainer usually has a copy of his package in /var/abs/local or
> something like that. So to keep his own copy updated and syncronized
> with AUR it's better to make the changes locally, build a new package
> and upload it to AUR like it is done now. And I don't think it's so
> complicated.
> 
> Why a "vote orphan" button? Orphaning is only necessary if the
> maintainer doesn't update the package for some time (several weeks)
> while upstream has released one or more new versions, and if the
> maintainer doesn't reply to comments and private e-mails for several
> weeks (at least two or three due to possible holidays). And in this
> case it is only necessary if a specific person wants to update and
> maintain the package. This is not a democratic question.
> 
> So if these conditions are fulfilled then the person who wants to
> adopt the package can easily write an e-mail to the mailing list. And
> a TU can review it. A package is usually orphaned within minutes,
> sometimes even seconds.
> 
> That's among others what TUs are for. They are users who are
> trustworthy (hopefully ;-) ) and who have some knowledge.
> 
> I don't think that it's very trustworthy, if normal users could vote
> for orphaning and if a package with enough votes for orphaning would
> be deleted automatically. And who will then adopt this package when
> it is orphaned? Then you had an orphan just because a handful of
> impatient people think the maintainer is not fast enough despite
> having good reasons for not updating the package. And believe me
> there are a lot of those impatient people out there. I saw this quite
> often in the comments for my packages particularly my kernel package.
> And I'm pretty sure that most of those voters wouldn't really want to
> adopt and maintain these packages.
> 
> Btw., this would not reduce the orphan requests. In fact it would
> increase the orphans, possibly not the requests but the automatic
> orphans.
> 
> So there should not be done too much automatically in AUR. Doing
> things manually could sometimes be better.
> 
> Heiko

I fully agree with Heiko, there should be no automation at all, the
furthest step scripts should do, is to notify us TUs that we should
take a look at something and operate accordingly. Also users shall not
have the possibility to delete their packages. There was a case with a
TU who removed his stuff before he left Arch in anger and that was bad.
Also there was an user in the last months who asked several times for
different old packages to be removed, which later revealed to be just
old packages, which were still working fine when built and did not break
any rule. He does a great job by checking old packages, though if he
had the privilege to remove those packages and did so in hurry, once we
would've found out about that later, that would've left a pretty bad
taste for him.

Lukas Fleischer created with aurdupes a script which makes the search
for duplicates pretty easy for us and I'm very thankful for that, as I
can run it once a day with a cronjob, get the results via mail and
check if someone else has already taken care of it. Also our latest TU,
Jakob Gruber is currently working on something that will make the checks
of old orphans easier so that a part of your wishes will come true, we
will take care of old orphans, at least those which don't fit into AUR
anymore.

Thorsten
-- 
Jabber: atsutane at freethoughts.de Blog: http://atsutane.freethoughts.de/
Key: 295AFBF4     FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 222 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/aur-general/attachments/20100920/cb332872/attachment.bin>