Optimized images

Brian Smith brian at briansmith.org
Fri Sep 13 09:18:56 UTC 2013

On Wed, Sep 11, 2013 at 7:17 PM, Mike Connor <mconnor at mozilla.com> wrote:
> I like the idea of tacking it onto the HSTS/blocklist update commit. Doing
> this once a week seems like more than enough to ensure a general state of
> good repair in terms of our image inventory. For bonus points we could tack
> it onto the train merge work flow to ensure late changes don't make it to
> release, but I don't think this is essential, since in the worst case late
> image additions would get cleaned up in the next release.

If we're going to have an automated task, I don't think it is
necessary for the automatic task to try to automatically fix the
problem. It should be good enough for the automatic task to simply
whine about the problem just like Talos whines about regressions. I
actually don't think such automation is even necessary. People who
check graphics into the tree should know to periodically run pngcrush
everything" and looking at "hg status" afterward. This is basically
jst-review.pl for graphics people. Also, reviewers could say "hey,
don't forget to pngcrush those graphics" as part of the normal process
of nitpicking whitespace and other style issues to death.

> Of course, this is all sanity checking, and we can also hand our visual
> designers a script to automate this prior to attaching images in the first
> place. That was standard practice a while back, at least.

Indeed, bugzilla could do the pngcrush at attachment time and flag the
attachment visually as "not optimized" (automatic r-?).


More information about the firefox-dev mailing list