Justin>GPL files with classpath exceptions are not allowed [1]
Justin, could you please elaborate?
The link in [1] you mention reads "Special exceptions to the GNU GPL (e.g.
GNU Classpath)"
If "GPL with classpath exception" is not allowed, then **all** ASF
Java-based projects violate the policy
Most JMH source files (e.g. see [1]) have the same license as
java.lang.String.
Do you exclude files that use `java.lang.String` from the release? I doubt
so.
The same goes for the benchmarks.
>Or, we can exclude the benchmark code from the release like [4] but
>still hold it in the VCS.
There's
> n this way, the automation would be triggered
>at the formal tag pushed
>after the vote passed.
Correct me if I am wrong, however, if a release vote includes only sources,
then creating and publishing binaries separately would violate the release
policy.
Creating the binaries and publishing
> Where [1] is still the most popular solution for Android Studio,
but the last activity was in Nov 1, 2017.
Up to date Darcula theme soures are located in IntelliJ Platform Git
repository.
I might be wrong, however, [1] never represented a theme that was used in
IntelliJ Platform.
There's a
> If the current owner of the code base is not acting in the best interest
of the wider community, then that might be a reason for it to be considered
Frankly speaking, my experience with Elm is limited to watching talks and
reading blogposts,
however, I incline that the code owner does ignore
> You are right about that, and I think that ultimately could prevent it from
> happening
Can you elaborate?
Suppose Apache Bicycle project takes the current Elm code in a source
form and evolves it.
It should be pretty much possible.
BSD-3 code may be included in Apache projects.
BSD-3 does
I have a similar tool in form of a Gradle plugin:
https://github.com/vlsi/vlsi-release-plugins/blob/45865c3186a7ecc0d30b1f88c2f31160b5e1b13a/plugins/license-gather-plugin/README.md
It searches for LICENSE-like files in dependencies, checks if the license
is A-B-X compatible,
and generates the
Ralph>I was busy
The world is on fire with log4j, so if you have no time left for 1.x, then,
please, just let others do the maintenance.
Ralph>My recollection was me saying if I had the code in a git repo getting
it into a GitHub repo would be easy.
I do not want to dilute "svn -> git" question
Matt>Attaching patches to Jira is exactly how v1 was developed back in the
day. V2 did it for some time as well before migrating to git
Matt, let us please refrain from off-topic discussions here? (at the end of
the day, this is "Looking for a champion" thread)
If you have objections or comments
>I would propose to talk with logging PMC first
I did exactly that, and they did not listen. They have no will to keep
releasing 1.x versions.
At the same time, they do not allow others to release log4j:log4j:1.x
versions.
I'm waiting for the response by Logging PMC chair Ron once again:
Romain,
Romain>for now the thread is looking for options which are not needed from
my window
It was the Logging PMC team who suggested I should re-incubate log4j 1.x.
Romain>1. where is the patch needed to fix the desired CVE? - must be
compatible
with current SVN trunk
The current SVN trunk
Matt>Nobody in the Logging PMC is blocking a release here.
Matt, thanks for the reply, however, it is false :(
I see you are positive, however, many more replies were quite negative.
Ralph Goers says: "We’ve stated several times that we don’t think
resurrecting Log4j 1.x permanently is a good
>Just wondering, is it even fulfilling the criteria of incubation?
I believe, the world does not need "active development in log4j 1.x"
nowadays.
What everybody needs from log4j 1.x is to fix security issues, fix
outstanding issues (if any),
keep the project buildable (e.g. avoid using outdated
>Do you have "facts" (like message on mailing list) ?
I am not sure what you mean.
For example:
1) Ralph Goers says the existing committers did not touch 1.x code a lot:
https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
Ralph>Virtually all of the contributors to the Log4j 1.x
JB>Anyone can propose new releases on any branches (including old ones).
JB>If you need my support/help on this, please let me know.
I and the other contributors tried to suggest PRs, however, log4j pmc
actively denies them.
They suggest contributors should focus on polishing log4j 1->2
Hi,
I want to resurrect log4j 1.x to fix well-known security issues.
I'm looking for the champion and committers.
log4j 1.x is a wildly used logging library, so releasing a secured version
would silence CVE warnings
all over the world, and it would enable users to focus on more relevant
tasks
16 matches
Mail list logo
