Re: [Tails-dev] review and merge feature/6999-compress-png

Hi,

sajolida wrote (06 Mar 2015 17:40:16 GMT) :
> How do I delete a branch on the remote directory?

git push origin --delete feature/6999-compress-png

>> Now, regardless of what we do with *existing* images, it would be good
>> to have "something" that prevents poorly compressed images from being
>> *added* to Git.
>>
>> There are a lot of candidate solutions, [...]

> I must admit that I'm not really excited at over-engineered solutions
> with hooks and all.

Fair enough :)

> I'll try to come up with two other possible low-fi
> techniques but they would require adding two copies of each images to
> Git (the uncompressed first, and then the compressed version and you
> might not like them:

> 1. Couldn't we say that we continue adding uncompressed images happily
> like we did in the past and that on a regular basic (release time, once
> a year, or anything else) we spot images that are in master and haven't
> been compress yet (merged since the last time we compressed images for
> example), and then compress those ones only.

I dislike this one (surprise! :), because it will progressively ruin
the effort we've put into making our Git repo smaller.

But I could be fine with trying it, recompressing in 6-9 months, and
at that point (*before* pushing to our repo, thanks), evaluating
what's the impact on .git's size of storing these images twice,
compared to what it would be if the optimized version had been pushed
initially. I'm not volunteering to do this evaluation.

> 2. We try our best to compress images before adding them. If the
> compression process is manual and quite cumbersome, we should be able to
> remember to specify in the commit messages if we did the compressing.
> Then uncompressed images could be spotted based on that every now and
> then and compressed.

Works for me. This should be communicated very clearly to the people
working on the test suite, as these days *they* are the ones who're
adding lots of (probably poorly compressed) images to Git. I can do
that latter part once the process is documented.

> Of course, this only make sense if we get a compression rate that is
> worth doing all that stuff... so maybe we should investigate c) before
> deciding on this and seem how the result affects the final ISO size.

Exactly. I bet a couple doc branch reviews that the test results will
tell us that mksquashfs is simply good enough.

Cheers,
--
intrigeri