+1 Small increments seem prudent until there is some understanding of where we want to go.
Ralph > On Oct 14, 2017, at 11:10 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > Hi Matt, > > It seems to me that to get out of the mess we are currently in, we need to > publish something official ASAP, even it is just an alpha or beta. > > Toward this goal, we should make the least amount of changes as possible. > Changing the source to 1.6 seems like a requirement to use modern tooling. > > Then we can take it one step at a time. I like the idea of having a longer > term road map, which, based on your messages, would be a long one full of > milestones! :-) > > I'm not sure how much I'll be able to help but you can count on me here and > there ;-) > > Gary > > On Sat, Oct 14, 2017 at 12:01 PM, Matt Sicker <boa...@gmail.com> wrote: > >> First off, for some reason, there are two repositories: >> >> https://github.com/apache/chainsaw >> https://github.com/apache/logging-chainsaw >> >> The second one appears to be up to date. Not sure what to do about the >> first one as it seems to be a relic of when Chainsaw was in SVN. >> >> Next, bug tracking. The pom says its bugs are tracked in Bugzilla. It was >> tracked as a component of Log4j 1. See this: < >> https://bz.apache.org/bugzilla/buglist.cgi?bug_status=__open__&component= >> chainsaw&product=Log4j%20-%20Now%20in%20Jira>. >> I believe it would be useful to switch over to JIRA like we're using for >> the rest of the logging projects. Perhaps we can ask infra for some sort of >> issue transfer if possible. >> >> Another issue: the Java source version is set to 1.4. That means it doesn't >> even compile using Java 8 due to 1.6 being the oldest source version >> usable. That also means that this project hasn't been updated to use >> generics let alone anything else from the past 13 years (Java 5 was >> released in 2004 back when I was learning how to program in the first >> place!). As such, incrementing the base Java version to 1.6 would be a >> minimum change, and I think if we increased to Java 8 or 9 after a release, >> that would give us a nice opportunity to do some mechanical refactorings >> and such which can sometimes be fun. >> >> Really, though, the choice of Java version or JVM language in general for a >> modernized version should be determined by whoever is interested in helping >> clean everything up and move forward. In that case, since I feel a bit >> interested here, I'd propose going with either Java 9 or Scala 2.12 (Scala >> provides a neat Swing API wrapper as well). Kotlin could also be a >> contender here, though I haven't used it much at all yet, so I can't really >> make a real recommendation there. There's also the option of migrating from >> Swing to JavaFX if there is interest, though I've never really used JavaFX >> before (but have used Swing). >> >> Then there is the notion of distribution. Since this is a GUI app, it's not >> generally as simple as just publishing to Maven Central. Naturally, the >> standard Apache release process of publishing sources and binaries to SVN >> works fine, but there are additional options we can consider: >> * Publish a Java webstart thing (would require working with infra to get >> the releases signed; current build instructions tell the user how to create >> their own release using a signing key and such) >> * Publish a macOS .app bundle. This can be published through our normal >> release channel, but there may also be a way to publish to the Mac App >> Store. Also, a Homebrew formula (or cask) for this would be nice, though >> they're normally maintained by external package maintainers just like in >> GNU/Linux distros. >> * Publish a native-ish Windows bundle. I don't see anything in the build >> already, but there are some tools out there to distribute a Java GUI app >> for Windows that could be useful here. >> >> I have other ideas I'd like to see such as adding support for the JSON >> layout and future binary layouts (e.g., Avro/Thrift/Protobuf/custom binary >> logging format) so there is no reliance on serialized log events or dealing >> with ambiguous log files. I'm pretty sure I could come up with a nice >> backlog here, and we could try to recruit some interested developers >> through helpwanted.a.o and potentially next time we have Google Summer of >> Code or other similar hackathon-like things. In general, I always find the >> viewing and searching of logs to be a pain regardless of fancy tools like >> ELK or Graylog or Splunk, and having a nice local GUI to sort through it >> all could be super useful, and I'd be interested to see this succeed in >> that. >> >> With all that in mind, who would be interested in helping out on this? I'm >> having difficulty with the current version getting compiled let alone >> getting a release cut, so I'm not even sure how feasible it would be to cut >> a release before going ahead with the next generation. If we start working >> on a major version of Chainsaw without a release for the existing code, >> would that need to take place in the incubator, or can we go forward here? >> >> -- >> Matt Sicker <boa...@gmail.com> >>
