I think a more specific problem was that nobody on the PMC knows much about this component. The active developers are committers and contributors currently.
On Tue, Aug 4, 2020 at 01:01 Tobias Frost <t...@debian.org> wrote: > 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> > -- Matt Sicker <boa...@gmail.com>
