On Sat, 2014-07-05 at 18:29 +0100, Steven Honeyman wrote:

Does anyone else think there is now just one thing missing from the "request" feature (or a different link)? I keep thinking "this package is broken" or "this package needs attention" (for reasons other than being out of date or abandoned), and there isn't a suitable button! Yes, the maintainer *should* be watching the comments, but that's very often not the case.

Currently, I think my only choices are: 1. Flag as "to be orphaned" (even though I know the maintainer is still active) 2. Flag as "out of date" (even though it isn't)

Examples might include: VCS packages that no longer build properly; or PKGBUILDs that do something unintentional (copy a file to the wrong directory, etc); or packages that don't build anymore because of a changed dependency.

Just wondered if those would be considered reasons for flagging as "out of date", or if anyone agrees this would be useful to have?

How about adding a "needs attention" checkbox when submitting a comment that, when checked, would email the maintainer and raise an "attention requested" flag on the package display page? The maintainer could check an "AR reset" checkbox when submitting his/her own comment, which would clear the flag. Carl

On 5 July 2014 14:23, Lukas Fleischer wrote:

...

Hello,

I am pleased to announce that AUR 3.3.0 has just been released. The official AUR setup [1] has already been updated.

This release includes several improvements to the package request feature and a couple of bug fixes.

For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the AUR bug tracker [3].

[1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aur.git/log/?id=v3.3.0 [3] https://bugs.archlinux.org/index.php?project=2

Wouldn't this push more work towards the AUR maintainers though? What actually happens when someone requests a package is to be orphaned? Can the package maintainer "un-request" it by doing something? I guess I just assumed (like the ML previously) that a bunch of people would get an email with the request in it - which nobody really wants to see! Definitely agree on the comment+checkbox idea being a bad one. As you said, everyone's problem would demand attention. Steven. On 5 July 2014 19:39, A Rojas wrote:

Carl Schaefer wrote:

...

How about adding a "needs attention" checkbox when submitting a comment that, when checked, would email the maintainer and raise an "attention requested" flag on the package display page? The maintainer could check an "AR reset" checkbox when submitting his/her own comment, which would clear the flag. Carl

This is calling for abuse. Almost everybody will consider their problem to be worth of attention. Maintainers should be subscribed to be notified of comments in their packages. If they're not, then they're not doing their job properly and requesting orphaning is justified IMO.

The trouble is there are too many people that don't (or can't) think about *why* something might not be working. It's often the users' fault :) Suppose someone sets ld.gold as their default linker "because the internet told them it was better"... and then tries to compile imagemagick... Steven. On 8 July 2014 12:30, Attila Bukor wrote:

There are two types of comments imho: a) discussion about how the package should be improved, etc; b) the package doesn't build in some cases, which *needs* attention from the maintainer.

Even in case the maintainer is subscribed to notifications, they can miss these b) kinds of comments if there are lots of discussion no the package. For this there should be a "flag not working" next to the "flag out of date" button. Just my two cents.

r1pp3rj4ck

On 07/05/2014 09:59 PM, Steven Honeyman wrote:

...

Wouldn't this push more work towards the AUR maintainers though? What actually happens when someone requests a package is to be orphaned? Can the package maintainer "un-request" it by doing something?

I guess I just assumed (like the ML previously) that a bunch of people would get an email with the request in it - which nobody really wants to see! Definitely agree on the comment+checkbox idea being a bad one. As you said, everyone's problem would demand attention.

Steven.

On 5 July 2014 19:39, A Rojas wrote:

...

Carl Schaefer wrote:

...

How about adding a "needs attention" checkbox when submitting a comment that, when checked, would email the maintainer and raise an "attention requested" flag on the package display page? The maintainer could check an "AR reset" checkbox when submitting his/her own comment, which would clear the flag. Carl

This is calling for abuse. Almost everybody will consider their problem to be worth of attention. Maintainers should be subscribed to be notified of comments in their packages. If they're not, then they're not doing their job properly and requesting orphaning is justified IMO.

On Wed, 09 Jul 2014 at 09:56:18, Attila Bukor wrote:

On 07/08/2014 06:27 PM, Steven Honeyman wrote:

...

The trouble is there are too many people that don't (or can't) think about *why* something might not be working. It's often the users' fault :)

Suppose someone sets ld.gold as their default linker "because the internet told them it was better"... and then tries to compile imagemagick...

Steven.

What if it would be a vote-like structure and one reporter wouldn't be enough to flag it as not working?

Dan suggested something similar some time ago [1] and I quite like that idea. One "Mark package broken" button and an option to sort package search results by the number of users that marked a package.

r1pp3rj4ck

[1] http://mailman.archlinux.org/pipermail/aur-dev/2011-June/001698.html

Maybe there should be an auto-orphan feature after x days/weeks if the package was out-of-date or being flagged for broken y times.

Just reported https://bugs.archlinux.org/task/41140 Reference: https://mailman.archlinux.org/pipermail/aur-general/2014-May/028506.html Regarding out-of-date (not updated to the latest version), broken (build fails), incomplete (no systemd units), bad name (should be ruby-blah not rubyblah) or whatever else can be invented. The package needs to be updated no matter the reason for being flagged - thus, auto-orphaned so interested people can take care of it. Therefore I don't think differentiating between out-of-date, broken or whatever is useful for anything.

Many packages were (and probably still are) "broken" as they didn't conform the new infrastructure, yet - strictly speaking - they weren't out of date.

Think of "Flag package out-of-date" as "Package needs updating" not "Package version is out-of-date". -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu

On Wed, Jul 09, 2014 at 02:44:56PM +0200, Johannes Löthberg wrote:

On 09/07, Nowaker wrote:

...

... I don't think differentiating between out-of-date, broken or whatever is useful for anything.

The problem is that sometimes a package is out-of-date but can't be updated for various reasons.

I don't see the relevance to the point this seemed to be a response to. That package may be hard/impossible to maintain, true - but separate flags for 'out of date', 'broken', 'wont compile' wouldn't aid that situation any. In fact they might make it worse. I'd be concerned with having several such flags because most real life situations may not fit cleanly into one or the other flag category. So some users may flag the difficult to maintain package as "out of date", others might flag is as "broken", etc. Maintainers could even then use a passing-of-blame strategy to avoid doing anything: they can remove an "out of date" flag with the justification that it is not *technically* out of date, etc. If one flag just signifies that something is wrong that requires the maintainer's attention, it should be easier for users and for maintainers. -Jesse aka 'Trilby' on forums/AUR

On Jul 9, 2014 8:59 AM, "Evert Vorster" wrote:

...

I don't see the relevance to the point this seemed to be a response to. That package may be hard/impossible to maintain, true - but separate flags for 'out of date', 'broken', 'wont compile' wouldn't aid that situation any. In fact they might make it worse. Agreed

...

If one flag just signifies that something is wrong that requires the maintainer's attention, it should be easier for users and for maintainers. Yes, don't get hung up on a name. That button could just as easily have said: "Needs attention" and then it would cover all the bases.

Naming is important. Here's an idea: lets call them "comments". They can be freeform text so that you can explain why the package needs attention, rather than just pressing some weirdly labeled button and hoping the maintainer figures it out.

-- Evert Vorster Chief Observer WG Cook

...

Naming is important. Here's an idea: lets call them "comments". They can be freeform text so that you can explain why the package needs attention, rather than just pressing some weirdly labeled button and hoping the maintainer figures it out.

+1. A very powerful solution indeed.

Good, but limit the number of characters allowed. Is there not already a comments to the packages in aur? -- Evert Vorster Chief Observer WG Cook

On Wed, 2014-07-09 at 14:08 +0100, Evert Vorster wrote:

Is there not already a comments to the packages in aur?

;) Good point :).

On 09/07, Jesse McClure wrote:

On Wed, Jul 09, 2014 at 02:44:56PM +0200, Johannes Löthberg wrote:

...

On 09/07, Nowaker wrote:

...

... I don't think differentiating between out-of-date, broken or whatever is useful for anything.

The problem is that sometimes a package is out-of-date but can't be updated for various reasons.

I don't see the relevance to the point this seemed to be a response to. That package may be hard/impossible to maintain, true - but separate flags for 'out of date', 'broken', 'wont compile' wouldn't aid that situation any. In fact they might make it worse.

I was responding to auto-orphaning of all packages, even the ones that aren't out-of-date due to maintainer negligence, not specifically about having just one flag. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5

On 07/09/2014 04:07 PM, Jesse McClure wrote:

On Wed, Jul 09, 2014 at 03:31:10PM +0200, Johannes Löthberg wrote:

...

Why is it even possible for maintainers to unsubscribe from comment emails of their packages?

I wasn't aware of this possibility. That does not seem like a good idea to me either. Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed.

I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional. r1pp3rj4ck

There are three very recent instances I'd like to use in examples here where the situation "didn't seem right" regarding the Request/Flag out of date features: 1. mdocml[1] - The maintainer is a nice friendly guy, I've emailed him back and forth to help him with the recent issues... but he doesn't appear to subscribe to the comments, or have the free time to maintain the package fully. (i'm referencing the recent comments on it) P.S. it still isn't right, and yes, I have even provided him with a fixed PKGBUILD [2]... but as mentionned, he is busy elsewhere, and wrote in a comment "don't flag out of date if there is no new upstream version" 2. musl[3] - The maintainer is not willing/able to support clang users (all it really needs is a simple if/else adding for cflags). I submitted an orphan request, it was accepted[4] - but before I got home from work, he re-adopted the package and still hasn't fixed it! 3. pnmixer[5] - I'm now an active developer in this project and we've just finished updating it to gtk3 and fixed some major bugs. The package was already flagged out of date, so I submitted an orphan request, and it was rejected[6] stating "email the maintainer" - which seemed to be the opposite of what I was told by Lukas[7] Sorry that's a little bit link-heavy! Also thanks to the people that are working hard on improving the AUR - I've had many requests accepted in less than a couple of hours which is great, the above 3 I'm just highlighting as the "bad" occasions as they might help someone come up with an idea for how the process could become more refined. Thanks, Steven. [1] https://aur.archlinux.org/packages/mdocml/ [2] https://gist.github.com/stevenhoneyman/e1abfd3a434974b125bd [3] https://aur.archlinux.org/packages/musl [4] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000313.html [5] https://aur.archlinux.org/packages/pnmixer/ [6] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000307.html [7] https://mailman.archlinux.org/pipermail/aur-general/2014-July/029048.html On 9 July 2014 15:34, Nowaker wrote:

...

Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed.

Totally disagree. I always go to "My Packages" page to see if there's anything to take care of. That's because packages flagged out-of-date are red, which is awesome. Doing `for p in packages; do read latest comment done` manually doesn't sound like a good idea to me.

...

I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional.

The maintainer has to care about the discussion about their package. "Disable notifications" should point to "Disown package". <trollface/>

-- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu

1. The man pages are installed in /usr/share/man1 instead of /usr/share/man/man1 (etc) in the current PKGBUILD. Don't guess based on something you haven't tried or tested. 2. I couldn't care less about clang right now. I've never used it. I aim to support as many configurations as possible though. If it was a "dick move" then it should have been rejected. On 9 July 2014 18:18, Dave Reisner wrote:

On Wed, Jul 09, 2014 at 05:58:02PM +0100, Steven Honeyman wrote:

...

There are three very recent instances I'd like to use in examples here where the situation "didn't seem right" regarding the Request/Flag out of date features:

1. mdocml[1] - The maintainer is a nice friendly guy, I've emailed him back and forth to help him with the recent issues... but he doesn't appear to subscribe to the comments, or have the free time to maintain the package fully. (i'm referencing the recent comments on it) P.S. it still isn't right, and yes, I have even provided him with a fixed PKGBUILD [2]... but as mentionned, he is busy elsewhere, and wrote in a comment "don't flag out of date if there is no new upstream version"

Well, he's right. I see nothing resembling a "pending issue" here, so clearly the current workflow was successful. This is orthogonal to the idea that it could be improved.

...

2. musl[3] - The maintainer is not willing/able to support clang users (all it really needs is a simple if/else adding for cflags). I submitted an orphan request, it was accepted[4] - but before I got home from work, he re-adopted the package and still hasn't fixed it!

Wow, really? That's a seriously dick move on your part. The maintainer has chosen to make the package work with the Arch defaults. That you want to add extra complexity to support non-standard setups is something that he's entirely in the right to ignore. *You* should be the one accepting the extra burden.

...

3. pnmixer[5] - I'm now an active developer in this project and we've just finished updating it to gtk3 and fixed some major bugs. The package was already flagged out of date, so I submitted an orphan request, and it was rejected[6] stating "email the maintainer" - which seemed to be the opposite of what I was told by Lukas[7]

Seems like a matter of broken human processes. The maintainer seems idle, with their last login being ~6 months ago.

...

Sorry that's a little bit link-heavy! Also thanks to the people that are working hard on improving the AUR - I've had many requests accepted in less than a couple of hours which is great, the above 3 I'm just highlighting as the "bad" occasions as they might help someone come up with an idea for how the process could become more refined.

Just remember that it's a two way street...

...

Thanks, Steven.

[1] https://aur.archlinux.org/packages/mdocml/ [2] https://gist.github.com/stevenhoneyman/e1abfd3a434974b125bd [3] https://aur.archlinux.org/packages/musl [4] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000313.html [5] https://aur.archlinux.org/packages/pnmixer/ [6] https://mailman.archlinux.org/pipermail/aur-requests/2014-July/000307.html [7] https://mailman.archlinux.org/pipermail/aur-general/2014-July/029048.html

On 9 July 2014 15:34, Nowaker wrote:

...

...

Perhaps if any change is needed, we could just get rid of the 'flag out of date' button and remove the possibility to unsubscribe from comments. This way comments would be the unified mechanism of informing a maintainer that there attention is needed.

Totally disagree. I always go to "My Packages" page to see if there's anything to take care of. That's because packages flagged out-of-date are red, which is awesome. Doing `for p in packages; do read latest comment done` manually doesn't sound like a good idea to me.

...

I think it's ok for maintainers to opt out in case there's too much discussion in the comments, but at least they should receive a daily digest by default which they shouldn't be optional.

The maintainer has to care about the discussion about their package. "Disable notifications" should point to "Disown package". <trollface/>

-- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu

On 9 July 2014 18:39, Dave Reisner wrote:

I'm going by the comments. If there's (still) a problem, you haven't brought it up in the past 4 days since the maintainer updated the package. Orphaning the package in this case isn't reasonable.

I have, just through e-mail directly to the maintainer. I didn't request it was to be orphaned; someone flagged it as "out of date" because there was no other option to click such as "needs fixing" (which is how this discussion started...)

You clearly do care, otherwise you wouldn't have: a) tried to hijack the package b) brought it up here

My AUR packages don't support/aren't tested with clang... but if someone commented on one requesting and explaining a simple change so that more people are able to use it, then I would implement it.

On 09/07, Johannes Löthberg wrote:

On 09/07, Steven Honeyman wrote:

...

...

You clearly do care, otherwise you wouldn't have: a) tried to hijack the package b) brought it up here

My AUR packages don't support/aren't tested with clang... but if someone commented on one requesting and explaining a simple change so that more people are able to use it, then I would implement it.

Hijacking aside, there's a bug in some recent gcc's (reported in 4.8.2 and 4.9.0) which is avoided by that extra CFLAG.

And interestingly enough there's even a comment on the package about just this. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5

On 9 July 2014 20:37, Bartłomiej Piotrowski wrote:

Yes, I have accepted the request, then realized it's completely untrue and asked the maintainer to re-adopt it. Additionally I'm the one who flagged the package because, obviously, there is a newer release, not because it's broken. Do you really see the point in fixing compilation using clang when literally nothing in PKGBUILD references it? I do not.

Please stop wasting time, either people's and yours.

-- Bartłomiej Piotrowski http://bpiotrowski.pl/

That makes less sense than falconandy's responses. Firstly, musl 1.0.3 was released June 6th [1]. The AUR package was updated to this version on June 7th [2] - there is not a newer release, and 1.0.3 is still the current stable version. So if you did flag as out of date, it's *you* wasting his time. As for your second point, that's as stupid as saying "literally nothing in the linux kernel references <brand new laptop> so there's no point in fixing drivers for it" [1] http://git.musl-libc.org/cgit/musl/commit/?h=rs-1.0&id=30bd499ae1f62e9d2fad4282d42057083709e0eb [2] http://pkgbuild.com/git/aur-mirror.git/commit/musl/PKGBUILD?id=5588dabbf0bc6...

On 9 July 2014 21:28, Bartłomiej Piotrowski wrote:

If only you were curious enough to actually use musl at least once it would be clear to you that the branch naming scheme used by upstream is at least misleading. Whatever you do 1.1.x is newer than 1.0 and in many cases is more useful.

But sure, better whine about clang and make unrelated comparison to developemnt of drivers in Linux kernel. Good luck, you are going to need it a lot.

-- Bartłomiej Piotrowski http://bpiotrowski.pl/

"treat others as you would be treated; respect them and their views, even if you disagree with them." - Arch Wiki Are you really that ignorant/stupid/insulting? Here let me help you: (from http://www.musl-libc.org/download.html) ----------------------- Current Versions Mainline - 1.1.3 Stable - 1.0.3 ----------------------- Oh! did I forget to mention that it helps if you use bother to use the search facility once in a while. Click this: https://aur.archlinux.org/packages/musl-latest/ ...and check the submitter/maintainer/packager Steven. (aka stevenhoneyman if you STILL haven't realised!)

On Wednesday, July 09, 2014 09:39:50 PM Steven Honeyman wrote:

On 9 July 2014 21:28, Bartłomiej Piotrowski wrote:

...

If only you were curious enough to actually use musl at least once it would be clear to you that the branch naming scheme used by upstream is at least misleading. Whatever you do 1.1.x is newer than 1.0 and in many cases is more useful.

But sure, better whine about clang and make unrelated comparison to developemnt of drivers in Linux kernel. Good luck, you are going to need it a lot.

-- Bartłomiej Piotrowski http://bpiotrowski.pl/

"treat others as you would be treated; respect them and their views, even if you disagree with them." - Arch Wiki

Are you really that ignorant/stupid/insulting? Here let me help you:

(from http://www.musl-libc.org/download.html) ----------------------- Current Versions Mainline - 1.1.3 Stable - 1.0.3 -----------------------

Not to butt-in, but based on the website's description of the Mainline branch, that is the one that should be packaged by default, and the Stable branch should be the special case. "Mainline - 1.1.3 This series is actively developed but intended for use in production environments as long as appropriate testing is performed, and should be preferred whenever there is a need for supporting an arbitrary, expanding set of packages or environments."[1] "Stable - 1.0.3 This series does not add new features and avoids changes that might affect building packages against musl or using applications in environments where they are already known to work. It is intended mostly for developers targetting a fixed profile of application software and kernel, such as in embedded development. "[1]

Oh! did I forget to mention that it helps if you use bother to use the search facility once in a while. Click this: https://aur.archlinux.org/packages/musl-latest/

...and check the submitter/maintainer/packager

Steven. (aka stevenhoneyman if you STILL haven't realised!)

On 9 July 2014 21:40, Jonathan Arnold wrote:

And if the email bounces, the package should be automagically disowned.

Not a good idea, if there was a temporary problem with a mailserver it would result in unsolicited orphaning of packages.

On 09/07, Florian Pritz wrote:

On 09.07.2014 22:20, Lukas Jirkovsky wrote:

...

On 9 July 2014 21:40, Jonathan Arnold wrote:

...

And if the email bounces, the package should be automagically disowned.

Not a good idea, if there was a temporary problem with a mailserver it would result in unsolicited orphaning of packages.

Email doesn't bounce because of temporary issues, otherwise stuff like graylisting would be even more annoying than it already is.

Normal retry times are 3 to 5 days with 5 being the postfix (and probably other software) default. If a mail couldn't be delivered after that time the sending server will bounce it.

Still seems excessive from just bouncing once. Having an email sent to one of the AUR mailinglists seems like a better option, that way it can be investigated if the maintainer really is gone or if he just forgot to update his email on the AUR. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5