Re: svn commit: r1790806 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

On Tue, Apr 11, 2017 at 6:39 AM, Jim Jagielski  wrote:
>
>> On Apr 10, 2017, at 11:55 PM, William A Rowe Jr  wrote:
>>
>>> - -1: wrowe (Premature, waiting on github.com/google/brotli 0.6 release)
>>> - NOTE: Awaiting next release post 0.5.2
>>
>> I'm amused by your rejection of my completing code review of this
>> submission, Jim. Classy.
>
> Bill, your veto is quoted above. As such, with the release of 0.6
> it was no long applicable.

And is my responsibility to remove, generally from one vote state to
another vote state. E.g. a -1 was blocking the release. Other reasons
for the veto had been stated on list, and

> As far as your problems w/ building brotli, maybe you simply aren't
> doing it right.
>
>  ../configure-cmake

You missed the step where you checked out github (via repo source
link, perhaps) so you were using v0.6.0.tar.gz vs Brotli-0.6.0.tar.gz
I had attempted to use... this wasn't distinguished in the package
names. (The later might better have been named Brotli_py-0.6.0);

Brotli-0.6.0.tar.gz
Brotli-0.6.0.zip
Source code (zip)
Source code (tar.gz)

Seems a complete source package is in the works, but v0.6.0.tar.gz
seems to be useable. Will be adjusting my vote shortly based on the
feedback in https://github.com/google/brotli/issues/539

Re: svn commit: r1790806 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

On Mon, Apr 10, 2017 at 10:55 PM, William A Rowe Jr  wrote:
>
> I was happy with the state of master as of Friday. I have not reviewed
> the final release package, however.

EFAIL

cd Brotli-0.6.0 && \
  cmake -G "Unix Makefiles" \
-D CMAKE_INSTALL_LIBDIR=lib \
-D CMAKE_INSTALL_PREFIX=../dst/httpd-2.4.x \
../src/Brotli-0.6.0 && \
cd ..
CMake Error: The source directory "../src/Brotli-0.6.0" does not
appear to contain CMakeLists.txt.

Was working Friday. Awkward :)

Re: svn commit: r1790806 - /httpd/httpd/branches/2.4.x/STATUS

[William A Rowe Jr]

On Mon, Apr 10, 2017 at 6:50 AM,   wrote:
> Author: jim
> Date: Mon Apr 10 11:50:26 2017
> New Revision: 1790806
>
> URL: http://svn.apache.org/viewvc?rev=1790806=rev
> Log:
> With v0.60 of https://github.com/google/brotli released,
> this is now viable again.

Agreed this is no longer 'being worked' but is again proposed...

> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Mon Apr 10 11:50:26 2017
> @@ -177,17 +177,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>protocol input, also seems unwise)
>jailletc36: needs r1790457 but can be merged afterwards. No 
> functionnal change.
>
> -PATCHES/ISSUES THAT ARE BEING WORKED
> -  [ New entried should be added at the START of the list ]
> -
> -  *) core: Disallow multiple Listen on the same IP:port when listener buckets
> - are configured (ListenCoresBucketsRatio > 0), consistently with the 
> single
> - bucket case (default), thus avoiding the leak of the corresponding 
> socket
> - descriptors on graceful restart.
> - trunk patch: http://svn.apache.org/r1789220
> - 2.4.x patch: trunk works (modulo CHANGES)
> - +1: ylavic
> -
>*) mod_brotli: Backport of mod_brotli filter
>   trunk patch: http://svn.apache.org/r1761714
>http://svn.apache.org/r1762512
> @@ -198,8 +187,17 @@ PATCHES/ISSUES THAT ARE BEING WORKED
>http://svn.apache.org/r1779699
>   2.4.x patch: http://home.apache.org/~jim/patches/brotli-2.4.patch
>   +1: jim, jorton,
> - -1: wrowe (Premature, waiting on github.com/google/brotli 0.6 release)
> - NOTE: Awaiting next release post 0.5.2

I was happy with the state of master as of Friday. I have not reviewed
the final release package, however.

I was very very happy with the huge documentation improvements
today. One key aspect I identified, that --deflate ++brotli is a net loss
for our examples, is unacceptable. Increasing the total traffic by ripping
out one universal compression method for a solution supported by only
half of the clients is, I'm sure you agree, a joke. Brotli can only be added
as a supplemental compression scheme in addition to gzip for older
clients at this time, particularly since the introduction of this compression
adds a large incremental cpu tax on the server.

I was disappointed to learn from the docs that input compression is not
even supported by the proposed enhancement. The browser clients
may not support it, but obviously other significant clients such as svn
should be adding it promply, the cpu cost to the clients pushing data
is not our worry at all, and the cpu cost of httpd decoding the brotli
compression is hardly measurable if not an actual win.

I'm amused by your rejection of my completing code review of this
submission, Jim. Classy.