[Development] Decrease amounth of delivered src packages

Matthew Woehlke mwoehlke.floss at gmail.com
Fri Feb 17 17:08:45 CET 2017


On 2017-02-15 05:38, Jani Heikkinen wrote:
> As you know we need to optimize our systems to be able to keep our 
> plans in the future. In CI side we are handling at least 4 different 
> branches at same time. Releasing side we should be able to do many 
> releases/snapshots parallel, test those releases/snapshots parallel
> etc. And all this needs lots of hw capasity (both calculating power &
> disc space).
> 
> We are trying to analyze the places where to do optimization and one 
> place is our src package creation and delivery: At the moment we are 
> doing, testing & delivering single src packages + separate submodule
> src packages, all these with .zip, .7z, .tar.gz & .tar.xz! Huge
> amount of src packages/snapshot/release. And currently doing these
> both for enterprise and lgpl! In the future (5.10?) we should be able
> to use unified ones meaning no separate LGPL & enterprise ones.

Are you actually doing *full testing* on all four of these? If yes, that
seems superfluous; it should suffice to do full testing on one each of
the UNIX and Windows line-ending packages, and for the rest, just verify
that their unpacked content is bitwise identical to one of the packages
that was fully tested.

The only cost for having both .tar.gz and .tar.xz should be disk space
and however long it takes to compress the package in the first place.
(Doubly so in this case because you can just `cmp <(gzip -c -d <
the.tar.gz) <(xz -c -d < the.tar.xz)` to validate that they are identical.)

> *:Download statistic:
> .7z      7%
> .tar.gz 44%
> .tar.xz 12%
> .zip     37%

12% is impressively high considering how much more difficult it is to
even find the .xz package rather than the .gz. (The main download page
only provides the .gz; to get the .xz, one must go digging about in the
archives.)

-- 
Matthew



More information about the Development mailing list