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 <enwuk...@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