Strictly speaking, you only need to add your key if you are going to be acting as the RM for a release. Adding the key to the KEYS file is something you can do yourself, it's just an edit and commit of the file.
Gary On Sun, May 25, 2014 at 7:39 PM, Matt Sicker <[email protected]> wrote: > Speaking of code signing, do I need to add my gpg key to a KEYS file or > something? As in submit it to one of you? Nick and I signed each others > keys at ApacheCon, and I got mine signed by several others there as well. > > > On 25 May 2014 18:14, Remko Popma <[email protected]> wrote: > >> I'll work on the code signing thing later when I get back from work. >> >> I added SimpleBenchmark, which does the same as SimplePerfTest: test the >> overhead of calling isXXXEnbled, isEnabled(Level) and logger.debug(). >> >> Not sure if you're interested in the throughput numbers too, or just the >> sampled response time. >> If your intention is to compare with Log4j-1.2 and Logback we should >> probably create similar benchmarks for those libraries. >> >> >> >> On Mon, May 26, 2014 at 7:40 AM, Ralph Goers >> <[email protected]>wrote: >> >>> Gary, dependencies on things used only during the build, like autoconf, >>> are ok. If the dependency is not part of the runtime there should be now >>> problem. I am pretty sure there is a Jira or an FAQ on this. >>> >>> Sent from my iPhone >>> >>> On May 25, 2014, at 2:25 PM, Gary Gregory <[email protected]> >>> wrote: >>> >>> Over in Commons VFS we are not adding a pom dep to a jar because it's >>> license is not ASF compatible, which is ASF policy from what I understand >>> and how it has been explained on the ML. Ii sounds like the same problem >>> here. >>> >>> Gary >>> >>> >>> -------- Original message -------- >>> From: Ralph Goers >>> Date:05/25/2014 02:26 (GMT-05:00) >>> To: Log4J Developers List >>> Subject: Re: JMH for log4j microbenchmarks >>> >>> This is a very good idea. You really don't have a lot to worry about. >>> ASF projects can use GPL tools to build or do things like you are >>> suggesting. However, we can't ship things that are under the GPL and should >>> not commit them to svn. From what you are describing I don't think we would >>> be doing that. >>> >>> The log4j-dist module controls what is included in the release. As I >>> recall it is already excluding some things so this be easy to do. However, >>> the release zips the whole source tree, so as long as there is nothing GPL >>> there we are good. >>> >>> Fwiw, my surgery is done. I am at home and feeling ok, under the >>> circumstances. I can only see from one eye right now so please excuse >>> mistakes. >>> >>> Sent from my iPad >>> >>> On May 24, 2014, at 10:42 AM, Remko Popma <[email protected]> wrote: >>> >>> I've been using JMH (http://openjdk.java.net/projects/code-tools/jmh/ ) >>> for performance tests recently and I'm very impressed. JMH is developed by >>> the Oracle java performance team and used internally by Oracle to >>> performance tune the JVM and java core libraries. >>> >>> I would like to use JMH to start building a suite of performance tests >>> for log4j2. I would like everyone's thoughts. First, do you like this idea >>> at all? >>> >>> Also, there is one legal and one technical aspect that I would like >>> everyone's feedback on. >>> >>> A potential legal problem is that JMH is made available under GNU GPL v2 >>> with the Classpath Exception, and our Apache License v2 is not compatible >>> with GPL v2 (see http://www.apache.org/foundation/license-faq.html#GPL). >>> >>> To solve this, I want to avoid distributing JMH or our executable >>> microbenchmarks (which would have the JMH classes) with our log4j >>> artifacts. I just want our team (and whoever checks out the log4j source) >>> to be able to use JMH to genyerate and run benchmarks when they want to. >>> >>> I'm not a lawyer though. Does anyone have experience with this kind of >>> question? >>> >>> The technical aspect: >>> I propose adding a log4j-perf module. This is where our performance test >>> code would live. JMH microbenchmarks are very simple java classes with >>> org.openjdk.jmh annotations. During the build, JMH generates code and that >>> generated code, together with all dependencies are zipped up in a large >>> uber-jar with the maven Shade plugin. You can then use java -jar >>> microbenchmarks.jar to run performance tests. >>> >>> To ensure that the log4j-perf artifacts are not included in the log4j2 >>> distribution, we could simply leave out the "<module>log4j-perf</module>" >>> line from log4j2/pom.xml. The drawback is that you'd need to manually add >>> that line and build again if you want to execute microbenchmarks to test >>> something that only exists in your workspace. Is there a better way, to >>> somehow include the log4j-perf module in the build, but exclude its >>> artifacts from the log4j2 distribution? >>> >>> >>> >> > > > -- > Matt Sicker <[email protected]> > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
