Size of release tarballs

  100098
July 29, 2017 10:56 ab@php.net (Anatol Belski)
Hi,

Lately there was a discovering about some files causing size growth of the release tarballs https://github.com/php/php-src/commit/469206c84e502e3e349655b802899d5e4d560f72 . Usually we strive to keep tarballs as small as possible and avoid disproportional growth of the size. This case seems to be of the exact nature. I would like to ask for an explicit response from RMs on this case.

Perhaps it were also a good point to discuss a way to prevent big binary files to land in the repo. So far some files in the repo can be big. Where text or code can be then compressed just fine - images, sound and other binary stuff can't. So this means the simple way of checking the file size in the pre-commit hook might get complicated, as check of the mime types might likely need to be involved. It were good to hear some ideas on a possible solution and whether some explicit rule on this were worthwhile.

Regards

Anatol
  100112
July 29, 2017 20:15 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Lately there was a discovering about some files causing size growth > of the release tarballs > https://github.com/php/php-src/commit/469206c84e502e3e349655b802899d5e4d560f72 > . Usually we strive to keep tarballs as small as possible and avoid > disproportional growth of the size. This case seems to be of the > exact nature. I would like to ask for an explicit response from RMs > on this case.
I'd say we probably should not include multi-megabyte images in the distros. Most tests should be fine with a small image.
> Perhaps it were also a good point to discuss a way to prevent big > binary files to land in the repo. So far some files in the repo can
I think we can handle it in the old-fashioned way now - just notify the RMs and clean up the repos. -- Stas Malyshev smalyshev@gmail.com
  100123
July 30, 2017 13:22 ab@php.net (Anatol Belski)
Hi Stas,

> -----Original Message----- > From: Stanislav Malyshev [mailto:smalyshev@gmail.com] > Sent: Saturday, July 29, 2017 10:16 PM > To: Anatol Belski <ab@php.net>; Sara Golemon <pollita@php.net>; Remi Collet > <remi@php.net> > Cc: PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Size of release tarballs > > Hi! > > > Lately there was a discovering about some files causing size growth of > > the release tarballs > > https://github.com/php/php- > src/commit/469206c84e502e3e349655b802899d5e > > 4d560f72 . Usually we strive to keep tarballs as small as possible and > > avoid disproportional growth of the size. This case seems to be of the > > exact nature. I would like to ask for an explicit response from RMs on > > this case. > > I'd say we probably should not include multi-megabyte images in the distros. > Most tests should be fine with a small image. > > > Perhaps it were also a good point to discuss a way to prevent big > > binary files to land in the repo. So far some files in the repo can > > I think we can handle it in the old-fashioned way now - just notify the RMs and > clean up the repos. > Yeah, there likely won't be any quick solution with commit hooks. I see Sara already did respond on GitHub, so some cleanups should be triggered.
Regards Anatol
  100129
July 30, 2017 19:41 pollita@php.net (Sara Golemon)
On Sun, Jul 30, 2017 at 9:22 AM, Anatol Belski <ab@php.net> wrote:
>> I think we can handle it in the old-fashioned way now - just notify the RMs and >> clean up the repos. >> > Some scripts for RMs to run periodically will get us 80% of the way
there, yeah. I don't mind tossing some together and updating README.RELEASE-PROCESS to reflect that duty. In fact, I think it might be worth breaking out this file into README.RELEASE-MANAGEMENT to cover non-release parts of the RM role (such as keeping an eye on out-sized files and that people observe merging process, etc...) -Sara
  100130
July 30, 2017 19:53 kalle@php.net (Kalle Sommer Nielsen)
2017-07-30 21:41 GMT+02:00 Sara Golemon <pollita@php.net>:
> On Sun, Jul 30, 2017 at 9:22 AM, Anatol Belski <ab@php.net> wrote: >>> I think we can handle it in the old-fashioned way now - just notify the RMs and >>> clean up the repos. >>> >> > Some scripts for RMs to run periodically will get us 80% of the way > there, yeah. I don't mind tossing some together and updating > README.RELEASE-PROCESS to reflect that duty. In fact, I think it > might be worth breaking out this file into README.RELEASE-MANAGEMENT > to cover non-release parts of the RM role (such as keeping an eye on > out-sized files and that people observe merging process, etc...)
I committed some changes which should reduce the exif tests by a larger margin in a7484beea2711c28f548d4c4e7cc10c5271b7890, I think this will help make the tarballs return back to normal -- regards, Kalle Sommer Nielsen kalle@php.net