Re: [DISCUSS] Flume 1.9 release proposal

I should also point out that the time to raise this was a year ago when the PR for FLUME-2050 was reviewed and committed. As it stands now I could be a jerk and vote -1 on the patch for FLUME-3296 with valid technical grounds. If this was causing a true binary incompatibility I would approve

Re: [DISCUSS] Flume 1.9 release proposal

One of the security issues is https://www.cvedetails.com/cve/CVE-2017-5645/ . It is reported against log4j 2 because Log4j 1 is EOL, but the same vulnerability exists there. RedHat has created a fix for Log4j 1 for its Linux distribution [1] but I

Re: [DISCUSS] Flume 1.9 release proposal

I wasn't aware of this security issue. Do you have a link to the details? There's no ASF requirement for package names; it's really just a Java language convention, and especially not enforced for compatibility shims. Even Flume has some of those in the legacy sources. I understand that it's

Re: [DISCUSS] Flume 1.9 release proposal

> On Nov 24, 2018, at 2:35 PM, Mike Percy wrote: > > Flume has long had a policy of backwards compatibility with its own > configuration files and people expect things to "just work" when upgrading > Flume. If log4j2 can't parse the log4j1 config file format then it's an > incompatible upgrade

Re: [DISCUSS] Flume 1.9 release proposal

Flume has long had a policy of backwards compatibility with its own configuration files and people expect things to "just work" when upgrading Flume. If log4j2 can't parse the log4j1 config file format then it's an incompatible upgrade and should not be done in a minor Flume release. If log4j2