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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
