[Cuis] Did we drop PNG support?

Sat Dec 21 07:11:38 CST 2013

Ok. I see your point.

Cheers,
Juan Vuletich

On 12/21/2013 1:03 AM, Casey Ransberger wrote:
> I hear what you're saying, Juan.
>
> Counter arguments:
>
> a) You're right, automated tests will not catch every possible bug. 
> But they'll catch some, sometimes, and that's more information than no 
> information.
>
> b) I think your statement here misses the point. The point is that 
> someone is *alerted* right away, generally by email, which is never a 
> bad thing.
>
> And I disagree with your statement that "people starts being less 
> careful about quality, believing that the CI server can compensate for 
> it." Obviously the CI server isn't going to fix bugs. IMHO, 
> implementing CI is by definition being *more* careful about quality, 
> not less.
>
> Let me put it another way: people won't run the tests. Even if you pay 
> them, they probably won't run the tests. Even if you convince them 
> that they're probably going to hell if they don't run the tests, 
> people still won't run the tests before they check in. I'm passionate 
> about testing, but you know when the last time I ran the tests was? It 
> was right before the last time we shipped a major version.
>
> Running the tests as often as every commit is never a bad thing; 
> having to do it manually though, is a pain in the ass.
>
> To be clear: I know how much you care about quality. I know that you 
> read every code submission very carefully, and you're keen to reject 
> code that doesn't meet your standards for quality, which are very 
> high. I've even see you rewrite bits of submissions to improve them 
> before including them in the system. You're right about one thing, 
> too, which is that no amount of automation can come close to the work 
> of a dedicated, passionate, and able human being.
>
> It's still worth doing, when the time is right. Eventually -- we 
> should hope -- the number of submissions will become burdensome. 
> Automated testing can reduce some of that burden, and let us know when 
> something has become provably broken, even if us volunteers are too 
> busy surviving to pay close attention that day.
>
> Juan does have a point here. He's controlling checkins to the core 
> system right now, and there aren't yet so many submissions that he has 
> to deputize other people to be able to merge submissions. I think it 
> will be when we reach the point where the number of submissions exceed 
> Juan's available time that we will very seriously need to think about 
> CI. I'm also glad to hear that he works in an image with the standard 
> non-core packages loaded. That alone greatly assuages the particular 
> concern I voiced.
>
> One last advantage of CI: the CI system can build multiple image 
> targets. This means it can cook us a core image and it can also cook 
> us a standard image. The latter is advantageous because it's probably 
> better that the easy-to-grab image we work in has "stuff we might 
> break" loaded already; it's arguably burdensome to load all the 
> external packages before beginning to work (I, for example, don't.)
>
> Anyway, these are just my views, and they aren't carved on stone tablets.
>
> Cheers,
>
> Casey
>
>
> On Fri, Dec 20, 2013 at 10:15 AM, Juan Vuletich <juan at jvuletich.org 
> <mailto: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
>
>     And people starts being less careful about quality, believing that
>     the CI server can compensate for it.
>
>     (Do I need to say names?)
>
>     Cheers,
>     Juan Vuletich
>
>
>     _______________________________________________
>     Cuis mailing list
>     Cuis at jvuletich.org <mailto:Cuis at jvuletich.org>
>     http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20131221/6e807815/attachment-0004.html>