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

intrigeri:
> 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

Done.

>> 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.

Ok.

> 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.

Added this idea to the ticket.

>> 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.

Sure, we should first see if we can get a better compression ratio and
if it has a real impact on the ISO size, and then only if it make sense
reconsider the process to enforce that in our Git.

--
sajolida