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 <d@falconindy.com> 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 <enwukaer@gmail.com> 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