Ok, I'm starting to see where you're coming from a bit better. As you can gather, I don't read every issue discussion (especially in packages) so I have not seen some of these things. Personally, I have always really appreciated your bug reports and fixed several myself. I hope to keep doing that.
Typically I have paid more attention to the julia issue tracker than to almost anything else, so to me stuff that's not there doesn't exist. (This is why Steve J had to file an issue to get me to write my thesis!) I'm sorry about the lack of email responses. However that does not mean I'm not receptive to bug reports. Applying my "received with gratitude" phrase to something completely different is confusing separate things. I'm sorry about your bug reports getting dismissed. I will try not to do that. In fact I just opened a bug for the UDP issue you referred to (Leah pointed me to it). However the context of responding to points in a blog post is utterly different. Writing a blog post is inviting debate. If you post stats that make a project look not-so-great, of course people will question them, wrong though they may be. To me that's acceptable, while being overly dismissive of bug reports is not. There are many kinds of bugs. If you file 20, it's quite possible that 5 will be fixed, 5 will sit around for a long time, 5 will be duplicates, and 5 will be dismissed for some reason. But that's still 5 fixed bugs, and to me that's how progress happens. On Tue, Dec 30, 2014 at 12:11 AM, Dan Luu <[email protected]> wrote: > Hi Jeff, > > > That's a lot of claims, so let me just respond to one, that my post > "implies ... that we don't understand our own code". > > Where I've been vague and imply something it's because I don't like > calling people out by name. > > I literally stated the opposite in my post, saying that the Julia core > team can "hold all of the code in their collective heads". > > I'm guessing the objection is to the line "code that even the core > developers can't figure out because it's too obscure", but that refers > to the vague anecdote in the previous paragraph. The plural here is a > side effect of being vague, not an implication that you can't figure > it out your own code. > > If it helps clear the air, the specifics are that when I ask Stefan > how something works the most common response I get is that I should > ask you or the mailing list since it's your code and he doesn't really > understand it. He could probably figure it out, but it's enough of a > non-trivial effort that he always forwards me to someone else. You > might object that I never actually emailed you, but that's because > I've seen what happened Leah emailed you, with plenty of reminder > emails, when she was working on her thesis and trying to figure out > things that would help her finish her thesis. Most emails didn't get a > response, even with a reminder or two, and I figured I'd get the same > treatment since I don't even know you. > > I understand that you must be incredibly busy, between doing your own > thesis and also being the most prolific contributor to Julia. But > perhaps you can see why, in this case, I might not expect my questions > to be "received with gratitude". > > There are some easily verifiable claims in my post that got > "pushback". That plotting bug? Probably because I'm using master, > which wasn't true and could have been checked by anyone with a release > build handy. That thing about build stats? Probably grabbing the wrong > numbers, which wasn't true, and could be easily spot checked by using > the script pointed in my linked post. > > In the past, I've talked to someone about the build being broken and > gotten the response that it worked for him, and when I pointed out > that Travis had been broken for half a day I got some response about > how Travis often has spurious fails. The bug eventually got fixed, a > few days later, but in the meantime the build was broken and there was > also a comment about how people shouldn't expect the build on master > to not be broken. I'm being vague again because I don't see calling > people out as being very productive, but if you prefer I can dig > through old chat logs the dredge up the specifics. > > Now, you say that responses to bug reports aren't responses to blog > posts. That's true, but perhaps you can see why I might not feel that > it's a great use of time to file every bug I run across when the > responses I've gotten outside of github bug reports have been what > they are. > > Sorry if I've caused any offense with my vagueness and implications > that can be read from my vagueness. > > > Best, > Dan > > > On Mon, Dec 29, 2014 at 10:39 PM, Tim Holy <[email protected]> wrote: >> For anyone who wants to help with the test coverage issue, I just posted some >> instructions here: >> https://github.com/JuliaLang/julia/issues/9493 >> >> --Tim >> >> On Monday, December 29, 2014 06:55:37 PM Ravi Mohan wrote: >>> Fwiw the correct engineering response here seems to be to acknowledge the >>> subset of Dan's criticisms that are valid/reasonable, fix those, and get >>> back to work. Criticising Dan's motives etc isn't a productive path (imo) >>> If there are low hanging fruit fixes on such a successful project,(the >>> build/test thing certainly seems to be one) that is a *good* thing. Yes the >>> HN crowd can be a bit rough (I am plinkplonk on HN, fwiw) , and often >>> unreasonable, but hey anyone running an open source project can't afford to >>> get disturbed by weird discussions on HN. >>> >>> All projects have bugs, and if someone has an uncanny knack for surfacing >>> heisenbugs, that is a good thing, irrespective of communication style. >>> >>> My 2 cents (I am just tinkering with Julia and don't use it anger yet, but >>> after some discussion with Viral (who is my neighbor) am considering >>> jumping in - Julia is a brilliant project). As a prospective contributor to >>> Julia, I am encouraged by Stefan's approach to this) >>> >>> regards, >>> Ravi >>
