And maybe the kinda 'last modification'/'history' logic the official packages' svn repo trunk thingy uses? The one where you can see the lines that were changed with the package, e.g. kernel26: http://repos.archlinux.org/wsvn/packages?op=comp&compare[]=/kernel26/trunk@89612&compare[]=/kernel26/trunk@90844 Thanks for your time, (sorry, if this mail went where it shouldn't have) Det

On Mon, 20 Sep 2010 22:16:27 +0200 Heiko Baums <lists@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@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

On 20.09.2010 23:11, Peter Lewis wrote:

On Monday 20 September 2010 at 21:56 Thorsten Töpper wrote:

...

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.

I agree too. I do think though that there is room though to standardise some of the processes through the use of scripts / buttons on the AUR (like proposing deletion to the TUs), for example to ensure that package names and links are always in the email and that one of the stated legitimate reasons applies. These should be designed to support the already agreed practice / process.

Cheers,

Pete.

Hi, 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. 2) mark as dublicate button - needs 3 (? to prevent abuse) votes from different users 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. 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. Another thing: Multiple maintainers would be realy nice... although anybody should put more thought into that, as it could easily become pretty messy. Cool think, i just can't make up a usecase for: http://mozillalabs.com/skywriter/ Cheers, Ulf

On Tuesday 21 September 2010 at 01:50 Ng Oon-Ee wrote:

On Tue, 2010-09-21 at 02:22 +0200, Ulf Winkelvos wrote: <snip>

...

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.

If they're not on the ML, a mechanism should be added for reporters to give reasons why packages should be disowned or removed. For some cases discussion will also be done here on the ML, would the reporter than not be part of the discussion?

I agree with this too am working towards implementing it. Since there are only certain given reasons for the deletion of a package (no sources available, no longer builds on current systems, duplicated elsewhere, source control system changed etc.) these could be check boxes to prompt the person proposing the deletion to think about these issues before clicking the button. There should also be a text field with which to elaborate. If all this is then sent to the mailing list automatically in a standard email, then it makes it very clear why the deleltion is being requested, by whom, the name of the package and a link to it. This can also alert the current maintainer (say in a cc). A discussion can then follow on the list in the usual way before a TU makes the final decision. I think this is likely to actually increase the signal to noise ratio in deletion request emails, since it will make the proposer think and be more likely to provide the needed information straight away. Cheers, Pete. PS. I agree with Heiko though that these issues (including orphaning and duplicate flagging are not democratic issues, they're just about establishing fact. Voting isn't needed.)

/snip I've always thought that there should be a TU dashboard for the AUR. It would collect all requests in a single area with regular formatting. Nothing would ever get lost in the list and users wouldn't need to sign up to it. Each request could have it's own comments page (using the existing comments backend) for discussion if necessary. Building on this idea, the package page could include a button named "notify maintainer". This would link to a form that allows a user to send a message to the maintainer, e.g. "please add x86_64" to the PKGBUILD. If the package isn't updated in e.g. 2 weeks, the "notify maintainer" button would be replaced by a "request adoption" button. Clicking on it would send a message to the dashboard, along with the previous message sent to the maintainer (including dates etc). Any TU could then review the message, the time that it was sent, and who sent it before deciding to orphan the package, with the bonus of the package being automatically adopted by whoever requested it. Deletion requests would go directly to the dashboard. This could be a simple form with a text field for the reason, e.g. "duplicate of foo", "no longer builds", "project moved to git", etc. Of course, in the absence of a dashboard, sending formatted messages to this list automatically would work too. In that case, maybe the submitter could be automatically signed up to the list (after a confirmation prompt while submitting).

...

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.

Maintainer groups would be really useful. Arch-Haskell would benefit from this. Currently the "arch-haskell" account is just Don and when he's busy none of the thousand+ Haskell packages can be updated. This has come up on the arch-haskell mailing list and he was working on a solution, but I haven't heard anything more about it. I have a few ideas of how that could be implemented on the backend, but it would just be another bikeshed discussion detracting from the one above. :P

On Wed 22 Sep 2010 01:20 +1200, Jonathan Conder wrote:

On 22/09/10 00:23, Xyne wrote:

...

Building on this idea, the package page could include a button named "notify maintainer". This would link to a form that allows a user to send a message to the maintainer, e.g. "please add x86_64" to the PKGBUILD. If the package isn't updated in e.g. 2 weeks, the "notify maintainer" button would be replaced by a "request adoption" button.

It would be nice to have something like this, like what we have on the forums, rather than having a plaintext email address exposed on the account.php page. If the user really wants to email the maintainer directly they could just look at a PKGBUILD.

On an unrelated note, does anyone else have problems with the MIME types on the AUR server? This is the header I get when downloading a tarball:

HTTP/1.1 200 OK Content-Type: application/x-tgz Accept-Ranges: bytes ETag: "2582334637" Last-Modified: Sat, 31 Oct 2009 01:58:19 GMT Content-Length: 425 Date: Fri, 10 Sep 2010 10:52:28 GMT Server: lighttpd/1.4.28

The MIME type for gzipped tarballs on my system is application/x-compressed-tar. It's kinda annoying because Firefox gets confused and decides it can't open the tarball. I might try to fix it myself at some later stage, but I'm really snowed under at the moment.

Interesting. Where is that set on your system? This whole mime type thing is a bit of a mess eh? I guess it's kind of hard to rely on non-standard mime types. Is there some kind of auxiliary non IETF standard? You can find the mime types that Firefox uses in: /home/<username>/.mozilla/firefox/<profileid>/mimeTypes.rdf Cheers.

Greetings, fellow all of you, Great talk about this subject but could a TU check the package list I handed out? All those packages still exist in AUR. Thanks for your time, Det

On 09/22/2010 07:13 PM, Jakob Gruber wrote:

Orphaned all except the following, thanks.

kpdf2: http://aur.archlinux.org/packages.php?ID=12299 (though, maybe not?)

network-manager-applet-notify-osd: http://aur.archlinux.org/packages.php?ID=34282

nvidia-173xx-ice: http://aur.archlinux.org/packages.php?ID=21059

otrtool-git: http://aur.archlinux.org/packages.php?ID=40775

ttf-anonymous: http://aur.archlinux.org/packages.php?ID=13389

..read 'Deleted all except...'

On 09/22/2010 09:31 PM, PyroPeter wrote:

On 09/22/2010 07:13 PM, Jakob Gruber wrote:

...

Orphaned all except the following, thanks.

kpdf2: http://aur.archlinux.org/packages.php?ID=12299 (though, maybe not?)

network-manager-applet-notify-osd: http://aur.archlinux.org/packages.php?ID=34282

nvidia-173xx-ice: http://aur.archlinux.org/packages.php?ID=21059

otrtool-git: http://aur.archlinux.org/packages.php?ID=40775

ttf-anonymous: http://aur.archlinux.org/packages.php?ID=13389

Hey, I am the maintainer (and developer) of otrtool-git. What's wrong about it?

Regards, PyroPeter I begin to understand what Det tried to explain with his post. He seems to have searched for the word "obsolete" in pkgdesc's.

otrtool-git's pkgdesc is: "Open source decoder for .otrkey files (onlinetvrecorder.com), makes otrdecoder-foss obsolete" So he actually recommends the deletion of otrdecoder-foss. That seems to be a good idea, so I also request deletion (as maintainer of otrdecoder-foss): http://aur.archlinux.org/packages.php?ID=40097 Regards, PyroPeter -- freenode/pyropeter "12:50 - Ich drücke Return."

On 9/22/10, Jakob Gruber <jakob.gruber@gmail.com> wrote:

On 09/22/2010 09:31 PM, PyroPeter wrote:

...

Hey, I am the maintainer (and developer) of otrtool-git. What's wrong about it?

Regards, PyroPeter

I guess Det searched aur.archlinux.org for the word 'obsolete' :)

Yeah, correct (Google). Figured the TU to remove(/orphan) these packages would be more pedantic than I could've been. Luckily in these kinda cases things can be reverted so no harm done in my or anybody else's part anyway. Thanks for your time, Det