On Mon, Aug 03, 2020 at 07:34:15PM -0500, Matt Sicker wrote: > Very well said! It helps get user feedback quicker, too.
+1! Also, the current "stable" has some many bugs (I carry 13 non Debian-specific patches in the current Debian package…) and a new release would also fix some open Bugs on the Debian BTS… I really would appreciate a new release… However, wasn't the problem in earlier tries to get log4cxx11 out of the door that noone remembered how a release is done for this project? (At least, /me as an outsider had that impression but I could have gotten this wrong). -- tobi > On Mon, Aug 3, 2020 at 19:03 Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > Here are my thoughts after working on several ASF projects for over 15 > > years. > > > > Theoretically logging projects should follow the “release early, release > > often” philosophy. There are a few good reasons why it should be that way. > > However, when you have a project with very few committers with limited time > > following that can be easier said than done. Personally, I like to set a > > goal for what I would like to see in a next release and try to meet that. > > However, it is more important to have semi-frequent releases than to get > > everything you wanted in. > > > > Longer release cycles typically make people try to cram more in at the end > > because they know it will be a long time until the next one. This can lead > > to bugs being introduced or designs not being well thought out. Releasing > > frequently avoids this and also provides immediate feedback on whether you > > are going down the right path with a new feature. > > > > Ralph > > > > > > > On Aug 3, 2020, at 4:49 PM, Robert Middleton <osfan6...@gmail.com> > > wrote: > > > > > > Thorsten, > > > > > >>> A number of these are rather large changes, so it probably > > >>> doesn't make sense to work on them until there's a known-good release, > > as > > >>> they would likely break both API and ABI compatibility. > > >> > > >> Does it really matter much if things are broken now vs. with 0.12.0 or > > >> alike? Backwards compatibility was somewhat broken already when > > >> changing how the macros are implemented, when returning new LevelPtrs > > >> to fix threading-issues and with introducing CMAKE in favor of > > >> building with Maven+ANT. > > >> > > > > > > I have a few thoughts on that: > > > 1. Having a known-good release means that there should be more users, > > > helping to better test the library. > > > 2. It depends on the level of backwards-compatability breakage that > > > there is. For people like you who have a limited environment, having > > > a version that does not depend on new C++ features allows for a > > > 'legacy' version and a 'modern' version. > > > 3. Adopting a semver[1] versioning at some point would probably make > > > sense. If there's an API breakage that should be properly documented > > > as part of the versioning. Arguably since this is technically 0.11.0 > > > version it doesn't really matter, since major version 0 allows major > > > API breakage. > > > > > >> Would be enough already if you would go through them and provide a > > >> second opinion about which of those could easily be closed. I would > > >> close ideas like APR database layer, CI-related stuff etc. most > > >> likely. Additionally some very old 0.9.7-related issues. But that > > >> keeps lots of other errors and improvements like new appenders. > > >> > > > > > > Here's my quick run-through of issues currently in JIRA: > > > LOG4CXX-490 - Should be easily fixable, but do we care about VS2015? > > > LOG4CXX-483 - Issue was resolved; I will create some documentation if > > > this comes up again though. > > > LOG4CXX-481 - I'm not sure who is the responsible member for this. > > > LOG4CXX-455 - This looks to still be an issue, although I'm not sure > > > what the correct way to do it would be. Maybe we add a new check to > > > also suppress exceptions? > > > LOG4CXX-454 - VS2013 issue, can probably be closed at the moment. > > > LOG4CXX-439 - Very old, not sure if still relevant at this point > > > LOG4CXX-438 - Very old, not sure if still relevant at this point > > > LOG4CXX-431 - Probably still an issue, but I think the best solution > > > here is to document and have a callback function that gets called > > > whenever a new thread starts, allowing the user to do their own signal > > > handling(a default implementation would be good too). e.g. > > > log4cxx::thread::setThreadStartFn --> called in new thread. > > > LOG4CXX-398 - It looks like this has already been fixed? > > > LOG4CXX-396 - Probably no longer relevant with CMAKE > > > LOG4CXX-389 - Very old and not enough information > > > LOG4CXX-384 - Very old and not enough information > > > LOG4CXX-377 - Very old and not enough information > > > LOG4CXX-374 - Very old and not correct usage of the library(using > > > std::endl in logging operation) > > > LOG4CXX-352 - Probably not an actual bug according to the comments > > > LOG4CXX-345 - Very old and not enough information > > > LOG4CXX-343 - Very old and not enough information > > > LOG4CXX-341 - Very old and not enough information > > > LOG4CXX-338 - Very old and not much activity, probably not an issue > > anymore > > > LOG4CXX-335 - Who uses sun studio anymore? > > > LOG4CXX-333 - Very old and likely not an issue > > > LOG4CXX-309 - Very old, probably not a bug in log4cxx > > > LOG4CXX-301 - Very old, probably best to close it out > > > LOG4CXX-289 - Very old, who uses Solaris anymore? > > > LOG4CXX-276 - Looks to be fixed > > > LOG4CXX-274 - very old at this point, may no longer be an issue > > > LOG4CXX-261 - Very old, who uses Solaris anymore? > > > LOG4CXX-260 - should be fixed as of LOG4CXX-457 > > > LOG4CXX-244 - Very old versions here, I don't see the point in keeping > > > this open. > > > LOG4CXX-205 - Very old issue, maynot be a problem > > > LOG4CXX-101 - Very old issue, unless somebody has a specific need to > > > use mysql this is almost certainly too old to be useful. > > > LOG4CXX-61 - Unless APR has database support(it doesn't seem too) this > > > should probably be closed > > > LOG4CXX-1 - I would say we should close this; any SMTP support may or > > > may not even work anymore > > > > > > There are a bunch of other old issues as well, but some of them at > > > least have potentially enough information to do something with. > > > > > > -Robert Middleton > > > > > > [1]: https://semver.org/ > > > > > > > > > -- > Matt Sicker <boa...@gmail.com>
