On Tue, Dec 21, 2021 at 1:51 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >So I am happy you agree to say that it involves PMC, whatever the time it
> >takes.
>
> If PMC can't allocate a minimal time for the release, they SHOULD be
> willing
> to transfer rights to the people who h
>So I am happy you agree to say that it involves PMC, whatever the time it
>takes.
If PMC can't allocate a minimal time for the release, they SHOULD be willing
to transfer rights to the people who have more time.
>If I may correct your formulation
My formulation is:
If somebody chimes in and doe
On Tue, Dec 21, 2021 at 1:26 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >To be a release manager , you need committer rights no ?
>
> No idea. It does not matter though. The contributor can do
> the heavy-lifting of composing the changelog, etc, etc.
>
> Of course, there will be
>To be a release manager , you need committer rights no ?
No idea. It does not matter though. The contributor can do
the heavy-lifting of composing the changelog, etc, etc.
Of course, there will be some work on PMC to formally vote, build from
sources, etc.
However, I believe it is not really tha
On Tue, Dec 21, 2021 at 1:17 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >Now regarding a fix to jmeter 1 or 2, well it’s your opinion as of now
>
> Philippe,
>
> Supposed someone chimes in and suggest releasing JMeter 3.x
> with log4j fixed. Suppose they would be open to do 90% o
>Now regarding a fix to jmeter 1 or 2, well it’s your opinion as of now
Philippe,
Supposed someone chimes in and suggest releasing JMeter 3.x
with log4j fixed. Suppose they would be open to do 90% of all the
heavy-lifting.
For instance, they might suggest a PR to make JMeter 3 buildable, they act
>so it’s really a straw man argument.
Please. Log4j 1.x -> 2.x upgrade is no way seamless.
I know lots of apps that do not need 2.x features, and that can't upgrade.
That is they are stuck with 1.x.
>There is nothing stopping people from forking log4j and using their own
fork
A fork under io.git
Hello,
When a free OSS library is publicly in EOL since many years, and you don’t
pay extended support to anybody, you know the risks you’re taking.
As a software developer I am very frequently frustrated by people refusing
the upgrade of libraries because it costs money and « doesn’t bring
anythi
Yes there are still people using COBOL, changing that is not a case of
upgrading a library though, so it’s really a straw man argument.
There is nothing stopping people from forking log4j and using their own fork,
if that’s a better option for them than upgrading to a 2.x version of log4j,
they
>People have had nearly a decade
... to remove COBOL from their apps.
Seamless migration does not exist yet, and people have large apps that
can't really be upgraded that easily.
They would rather fork log4j and use their own fork.
>This is more akin to asking the JMeter team to support JMeter 2
To be fair to the log4j team, version 1.12.x went into maintenance mode back in
2007 and they did a couple of minor updates in 2010 and 2012.
People have had nearly a decade since the last maintenance release to remove
this old dependency and plan/implement an upgrade to the 2.x.x releases.
Thi
Hello,
I think it's better to keep log4j, as there will be no real add value,the
only problem detected is related to security and can happen to any
Framework.
Best Regards
On Tue, Dec 21, 2021 at 11:05 AM Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:
> Hello Vladimir,
>
> I feel tha
>would you be happy
>to see our users abandon JMeter because a CVE is discovered
>but it can happen to any
>project (logback also had one although less impacting)
Consider a case:
1. A critical vulnerability is discovered in JMeter 3.0 (e.g. remote code
execution via HTTP client)
2. Multiple users
Hello Vladimir,
I feel that it's over engineering here. If we were starting a new project ,
I would be ok.
But this change here and now, does not bring major features to users (I
think logging works pretty nicely today), it will even
bring more work for them in case they don't know logback.
On a
Hi,
What do you think of replacing log4j2 with logback?
Even though it might sound like an over-reaction,
I believe it is the net positive thing.
The reasons are:
* log4j2 has lots of features, and we do not really need them
* lots of log4j2 are in-core, so a breach in one of them impacts the wh
15 matches
Mail list logo
