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. Whateve
On Wed, 9 Jul 2014 21:39:50 +0100
Steven Honeyman wrote:
> "treat others as you would be treated; respect them and their views,
> even if you disagree with them." - Arch Wiki
Thanks for making me realize that I'm the one who's trying to outsmart
everyone on aur-general and is so rude to say that
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
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.
>
On Wed, 9 Jul 2014 21:03:51 +0100
Steven Honeyman wrote:
> 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, obvio
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 package
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 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
On Wed, 09 Jul 2014 16:34:20 +0200
Nowaker wrote:
> > 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 discu
On Wed, 9 Jul 2014 19:00:10 +0100
Steven Honeyman wrote:
> 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
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 simpl
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 a
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 maintain
On Wed, Jul 09, 2014 at 06:28:21PM +0100, Steven Honeyman wrote:
> 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.
I'm going by the comments. If there's (still) a problem
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.
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
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 Packag
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.
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 ju
On 09/07, Dave Reisner wrote:
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.
Why is it even possib
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 u
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 9 July 2014 15:08, Evert Vorster wrote:
>>> 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 o
>> 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.
Go
On 9 July 2014 15:01, Dave Reisner wrote:
>
> 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
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
> 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 sign
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 rea
On 09/07, Nowaker wrote:
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
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 (n
On 07/09/2014 10:15 AM, Lukas Fleischer wrote:
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
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 t
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"... an
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.
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
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 th
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
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 aban
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 *sh
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
40 matches
Mail list logo
