[Cuis] Did we drop PNG support?

[Frank Shearar]

On 20 December 2013 18:49, Juan Vuletich <juan at jvuletich.org> wrote:
> On 12/20/2013 3:34 PM, Frank Shearar wrote:
>>
>> On 20 December 2013 18:15, Juan Vuletich<juan at jvuletich.org>  wrote:
>>>
>>> On 12/20/2013 1:16 PM, Frank Shearar wrote:
>>>>
>>>> On every commit, CI runs your entire test suite. When things fail, you
>>>> immediately know which commit broke the test, which gives you much
>>>> less code (hopefully) to analyse, to find the breakage. CI is all
>>>> about closing the feedback loop.
>>>>
>>>> Further, in GitHub's case, you can use Travis CI to handle the CI
>>>> part. Because the test suite runs against every commit, a pull request
>>>> will be validated (or not), and Travis CI can update the pull
>>>> request's commit status. This gives you, the reviewer of the pull
>>>> request, a green/red light, telling you that the PR doesn't break
>>>> anything.
>>>>
>>>> (For the seriously pedantic, the thing you _really_ want is to merge
>>>> the PR into the master and run the test suite on that. _That_ green
>>>> light should inform the commit status of the PR. Alas, no one actually
>>>> does that.)
>>>>
>>>> frank
>>>
>>>
>>> But all this assumes that:
>>> a) Tests will catch every possible bug
>>> b) Immediately after a test starts failing, someone will review the code
>>
>> No? Well, I don't assume that. The point is that when someone issues a
>> pull request against your codebase, _something/one_ needs to run the
>> tests. Why would you want to _have_ to do that manually, when a
>> machine can do it for you?
>
>
> Because I do it at the same time I carefully review the code myself. Then I
> can accept it or not considering my review and the tests.

I suppose I see CI as a tool to support the reviewer. If I see a green
commit status on a pull request, I at least know the code's not
obviously broken, not introduced a regression. It certainly doesn't
absolve me, the reviewer, of the duty to actually read the code. Using
CI, in my opinion, simply frees the reviewer to consider the code more
deeply, because the basic automated stuff's already taken care of.

>> Tests should catch every _found_ bug. As in: if you find a bug, you
>> write a test that demonstrates the bug. Then you fix the bug.
>>
>> If I cared about catching _every possible_ bug, I'd program in Coq or ATS.
>
>
> Yes. But the stuff that constantly breaks is stuff that was never the
> subject of a bug, and has no tests.

Well, sure, most of the time. Ideally of course no line of code gets
written without a test "pulling it into existence", so to speak. With
legacy code the lack of tests is a serious problem. Certainly that's
true in Squeak's case.

>>> And people starts being less careful about quality, believing that the CI
>>> server can compensate for it.
>>
>> I would far rather have tests, CI, code coverage tools than not :)
>> _My_ experience clearly doesn't match with yours.
>>
>>> (Do I need to say names?)
>>
>> If you mean _me_, you're mistaken. But tests that are not run might as
>> well not exist.
>
>
> Apologies, I didn't mean that, and I didn't mean to be rude. Everything I
> said (failed assumptions, lower quality, no good code review, broken stuff
> that was never a bug, etc) applies to Pharo. Or at least that's what I see
> in the Pharo mail list and what I heard from former Pharo users.

Ok, phew. Having been yelled at just the other day for breaking
things, I may still be a bit sensitive!

frank

> Cheers,
> Juan Vuletich