Very well said! It helps get user feedback quicker, too. 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>
