Re: [log4cxx] Feature Proposals
On Mon, Aug 03, 2020 at 07:49:14PM -0400, Robert Middleton 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. While the version is at 0.x.x, the at least the old auttools based build system declares SONAME to be 10 [1], so log4cxx is declaring a stable ABI/API. However, as said in an earlier thread, this is not a problem for a distribution (like Debian) as this is usual business to cope with ABI/API changes. (if it does not happen too ofthen, as a library transition means some work.) [1] The version currently in Debian: $objdump -p liblog4cxx.so | grep SONAME SONAME liblog4cxx.so.10 -- tobi
Re: [log4cxx] Feature Proposals
Very well said! It helps get user feedback quicker, too. On Mon, Aug 3, 2020 at 19:03 Ralph Goers 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 > 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
Re: [log4cxx] Feature Proposals
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 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
Re: [log4cxx] Feature Proposals
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/
Re: [VOTE] Release Log4Net 2.0.9
Thanks Remko. That makes 3 +1 votes from PMC members. Ralph > On Aug 3, 2020, at 2:12 PM, Remko Popma wrote: > > +1 Remko. > > On Tue, Aug 4, 2020 at 1:04 AM Matt Sicker wrote: > >> +1 from me. We can handle the release signing afterwards as Ralph suggests. >> >> On Mon, 3 Aug 2020 at 10:30, Ralph Goers >> wrote: >>> >>> Can other PMC members please review this? It has been more than 72 >> hours. >>> >>> Ralph >>> On Jul 30, 2020, at 11:17 PM, Davyd McColl >> wrote: Hi all, I've never done this before, so bear with me if I fluff it: This is a proposed vote to release log4net 2.0.9 from PR >> https://github.com/apache/logging-log4net/pull/61 Release artifacts (including source zip) are at: >> https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/34063235/artifacts Source can be checked out from >> https://github.com/fluffynuts/logging-log4net/logging-log4net, tag rel/ >> 2.0.9. I can't push tags to the upstream, but this tag is exactly the >> same commit as the last in the PR mentioned above, which was accepted into >> master a few days ago. Please check out the artifacts & if everyone is ok with what's there, >> please can someone with the rights to publish to nuget do so. Once I've seen how this process works, I'd like to tackle the CVE that >> has been brought up on this list more than once -- it's a simple change >> which was already committed to the develop branch some time ago, so there >> are a couple of options here: 1. cherry-pick that commit & do a 2.0.10 release pronto, with only >> that change 2. trawl the develop branch to see what else was already solved in >> there, and get that out as 2.0.10, and perhaps close out that branch to >> avoid future confusion. Thanks for your time -d >>> >>> >> >> >> -- >> Matt Sicker >>
Re: [VOTE] Release Log4Net 2.0.9
+1 Remko. On Tue, Aug 4, 2020 at 1:04 AM Matt Sicker wrote: > +1 from me. We can handle the release signing afterwards as Ralph suggests. > > On Mon, 3 Aug 2020 at 10:30, Ralph Goers > wrote: > > > > Can other PMC members please review this? It has been more than 72 > hours. > > > > Ralph > > > > > On Jul 30, 2020, at 11:17 PM, Davyd McColl > wrote: > > > > > > Hi all, I've never done this before, so bear with me if I fluff it: > > > > > > This is a proposed vote to release log4net 2.0.9 from PR > https://github.com/apache/logging-log4net/pull/61 > > > > > > Release artifacts (including source zip) are at: > https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/34063235/artifacts > > > Source can be checked out from > https://github.com/fluffynuts/logging-log4net/logging-log4net, tag rel/ > 2.0.9. I can't push tags to the upstream, but this tag is exactly the > same commit as the last in the PR mentioned above, which was accepted into > master a few days ago. > > > > > > Please check out the artifacts & if everyone is ok with what's there, > please can someone with the rights to publish to nuget do so. > > > > > > Once I've seen how this process works, I'd like to tackle the CVE that > has been brought up on this list more than once -- it's a simple change > which was already committed to the develop branch some time ago, so there > are a couple of options here: > > > 1. cherry-pick that commit & do a 2.0.10 release pronto, with only > that change > > > 2. trawl the develop branch to see what else was already solved in > there, and get that out as 2.0.10, and perhaps close out that branch to > avoid future confusion. > > > > > > Thanks for your time > > > -d > > > > > > > -- > Matt Sicker >
Re: [VOTE] Release Log4Net 2.0.9
+1 from me. We can handle the release signing afterwards as Ralph suggests. On Mon, 3 Aug 2020 at 10:30, Ralph Goers wrote: > > Can other PMC members please review this? It has been more than 72 hours. > > Ralph > > > On Jul 30, 2020, at 11:17 PM, Davyd McColl wrote: > > > > Hi all, I've never done this before, so bear with me if I fluff it: > > > > This is a proposed vote to release log4net 2.0.9 from PR > > https://github.com/apache/logging-log4net/pull/61 > > > > Release artifacts (including source zip) are at: > > https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/34063235/artifacts > > Source can be checked out from > > https://github.com/fluffynuts/logging-log4net/logging-log4net, tag > > rel/2.0.9. I can't push tags to the upstream, but this tag is exactly the > > same commit as the last in the PR mentioned above, which was accepted into > > master a few days ago. > > > > Please check out the artifacts & if everyone is ok with what's there, > > please can someone with the rights to publish to nuget do so. > > > > Once I've seen how this process works, I'd like to tackle the CVE that has > > been brought up on this list more than once -- it's a simple change which > > was already committed to the develop branch some time ago, so there are a > > couple of options here: > > 1. cherry-pick that commit & do a 2.0.10 release pronto, with only that > > change > > 2. trawl the develop branch to see what else was already solved in there, > > and get that out as 2.0.10, and perhaps close out that branch to avoid > > future confusion. > > > > Thanks for your time > > -d > > -- Matt Sicker
Re: [VOTE] Release Log4Net 2.0.9
Can other PMC members please review this? It has been more than 72 hours. Ralph > On Jul 30, 2020, at 11:17 PM, Davyd McColl wrote: > > Hi all, I've never done this before, so bear with me if I fluff it: > > This is a proposed vote to release log4net 2.0.9 from PR > https://github.com/apache/logging-log4net/pull/61 > > Release artifacts (including source zip) are at: > https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/34063235/artifacts > Source can be checked out from > https://github.com/fluffynuts/logging-log4net/logging-log4net, tag rel/2.0.9. > I can't push tags to the upstream, but this tag is exactly the same commit as > the last in the PR mentioned above, which was accepted into master a few days > ago. > > Please check out the artifacts & if everyone is ok with what's there, please > can someone with the rights to publish to nuget do so. > > Once I've seen how this process works, I'd like to tackle the CVE that has > been brought up on this list more than once -- it's a simple change which was > already committed to the develop branch some time ago, so there are a couple > of options here: > 1. cherry-pick that commit & do a 2.0.10 release pronto, with only that change > 2. trawl the develop branch to see what else was already solved in there, and > get that out as 2.0.10, and perhaps close out that branch to avoid future > confusion. > > Thanks for your time > -d
Re: [log4cxx] Feature Proposals
Guten Tag Robert Middleton, am Montag, 3. August 2020 um 02:17 schrieben Sie: > I'd like to propose some new features/updates for log4cxx, if there's > interest. Things mostly read good and interesting to me. Even though I would suffer myself a lot most likely, as my currently used compiler/IDE is mostly not even compatible with C++11. :-) > 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. We might not need to care too much in favor of implementing changes users benefit from. >3. Removal of maven for site generation.[...] The good thing about the current approach is that Maven does some things automatically, which would otherwise not be available or need to be maintained manually. Think of the changes-report, providing mailing list info, linking to issue tracker, even dependencies could be enhanced. Additionally, ANT is used to simply automate somewhat cross-platform things which would need to be implemented otherwise. Maven shouldn't be used for building anymore and not using it for releasing would simply require another implementation. Even though things seemed to have somewhat worked for you. So this doesn't read too important to me and things can be changed step-by-step: Change usage of ANT, using Doxygen at least as PoC for some sites can simply be added as Doxygen is already needed anyway etc. >4. ABI compatibility.[...] In general I prefer more straightforward class declarations and wouldn't care too much about changing each and every class to pimpl. >2. Remove the autotools build[...]Is >there a particular reason to keep it around still? AFAIK only backwards compatibility. >3. Support for log4j2-style XML/JSON/YAML documents.[...] For the time being, it might be far easier to document more on our own instead. Might be a good chance to add Doxygen-based content like you proposed. > Going through the currently open issues in JIRA, there's also a large > number that are either so old that they don't make much sense, or may have > been fixed already. Would it make sense to go through them at some point? > That's probably not something that I can do alone, but I can help to go > through them. 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. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
