Dan, I know there are many areas where we should improve. For now I
share Stefan's frustration about the mystery bugs you keep alluding
to. I don't expect a full detailed report on each one, and I get that
you don't want to interrupt work to file them. But we have now seen at
least two blog posts and one long list post inspired in part by these
bugs. If you have time to write all that, you have time to at least
send us your script. We have not often asked others to fix their own
bugs, and we have not been known to call people brats, but we have
been known to fix lots of bugs. I know fixing bugs one-by-one is not
as good as systematically improving our tests and process, but it is
more helpful than alarmist invective.

On Mon, Dec 29, 2014 at 4:45 PM, Steven G. Johnson
<stevenj....@gmail.com> wrote:
> On Monday, December 29, 2014 4:12:36 PM UTC-5, Stefan Karpinski wrote:
>>
>> I didn't read through the broken builds post in detail – thanks for the
>> clarification. Julia basically uses master as a branch for merging and
>> simmering experimental work. It seems like many (most?) projects don't do
>> this, and instead use master for stable work.
>
>
> Yeah, a lot of projects use the Gitflow model, in which a develop branch is
> used for experimental work and master is used for (nearly) release
> candidates.
>
> I can understand where Dan is coming from in terms of finding issues
> continually when using Julia, but in my case it's more commonly "this
> behavior is annoying / could be improved" than "this behavior is wrong".
> It's rare for me to code for a few hours in Julia without filing issues in
> the former category, but out of the 300 issues I've filed since 2012, it
> looks like less than two dozen are in the latter "definite bug" category.
>
> I'm don't understand his perspective on "modern test frameworks" in which
> FactCheck is light-years better than a big file full of asserts.  Maybe my
> age is showing, but from my perspective FactCheck (and its Midje antecedent)
> just gives you a slightly more verbose assert syntax and a way of grouping
> asserts into blocks (which doesn't seem much better than just adding a
> comment at the top of a group of asserts).   Tastes vary, of course, but Dan
> seems to be referring to some dramatic advantage that isn't a matter of mere
> spelling.  What am I missing?

Reply via email to