Re: [log4cxx] JIRA Updates and next release?
There are not many important changes. It looks like really only the following has changed: * LOGCXX-556 - issue with the syslog appender * Multiple process support for the BufferedWriter * Fix the build with Qt * Mocking the clock(really only relevant for unit tests) * Static initialization updates The good news is that making the release is very easy at this point. All you have to do is to define APACHE_MAINTAINER and do 'make dist' to generate the tar.gz/zip files and the checksums, build and upload the site to staging, and upload the binaries to the SVN repo for voting on. -Robert Middleton On Mon, Sep 26, 2022 at 9:13 PM Stephen Webb wrote: > > I just went through the differences between master and rel/v0.13.0 and the > only significant fix I saw in master was the crash in a statically linked > log4cxx library. > > While I am not familiar with the amount of work required to create a > release (it looks like a lot), I wonder if there are enough changes in > master to justify the work of creating a release. > > On Tue, Sep 27, 2022 at 11:02 AM Robert Middleton > wrote: > > > On Mon, Sep 26, 2022 at 5:09 AM Thorsten Schöning > > wrote: > > > > * Having better error reporting - many exceptions that are thrown are > > > > basically swallowed and just print out to stderr at the moment. Come > > > > to think of it, do we even want exceptions? It seems like a bad idea > > > > for the logging framework to throw exceptions > > > > > > What else do you have in mind, some error handlers and callbacks? > > > Throwing and swallowing at some point doesn't sound that bad, as long > > > as the problem is visible somewhere. Logback pretty mich logs on > > > STDERR or STDOUT only as well. > > > > > > > Yes, error handling and/or callbacks to notify the user. There are > > certain situations where there isn't much useful information available > > unless you're looking at STDERR, and even sometimes that information > > is pretty useless. For example, if you try to use the DOMConfigurator > > and the file isn't found, the only way for you to tell that something > > went wrong is to view the output of the process; this should probably > > return a bool or something to indicate that the configuration was > > successful or not. > > > > And then there's the incredibly unhelpful error message of "please > > initialize the log4cxx system properly" which should probably print > > out a bit more as to what it tried to do and why it failed. > > > > -Robert Middleton > >
Re: [log4cxx] JIRA Updates and next release?
I just went through the differences between master and rel/v0.13.0 and the only significant fix I saw in master was the crash in a statically linked log4cxx library. While I am not familiar with the amount of work required to create a release (it looks like a lot), I wonder if there are enough changes in master to justify the work of creating a release. On Tue, Sep 27, 2022 at 11:02 AM Robert Middleton wrote: > On Mon, Sep 26, 2022 at 5:09 AM Thorsten Schöning > wrote: > > > * Having better error reporting - many exceptions that are thrown are > > > basically swallowed and just print out to stderr at the moment. Come > > > to think of it, do we even want exceptions? It seems like a bad idea > > > for the logging framework to throw exceptions > > > > What else do you have in mind, some error handlers and callbacks? > > Throwing and swallowing at some point doesn't sound that bad, as long > > as the problem is visible somewhere. Logback pretty mich logs on > > STDERR or STDOUT only as well. > > > > Yes, error handling and/or callbacks to notify the user. There are > certain situations where there isn't much useful information available > unless you're looking at STDERR, and even sometimes that information > is pretty useless. For example, if you try to use the DOMConfigurator > and the file isn't found, the only way for you to tell that something > went wrong is to view the output of the process; this should probably > return a bool or something to indicate that the configuration was > successful or not. > > And then there's the incredibly unhelpful error message of "please > initialize the log4cxx system properly" which should probably print > out a bit more as to what it tried to do and why it failed. > > -Robert Middleton >
Re: [log4cxx] JIRA Updates and next release?
On Mon, Sep 26, 2022 at 5:09 AM Thorsten Schöning wrote: > > * Having better error reporting - many exceptions that are thrown are > > basically swallowed and just print out to stderr at the moment. Come > > to think of it, do we even want exceptions? It seems like a bad idea > > for the logging framework to throw exceptions > > What else do you have in mind, some error handlers and callbacks? > Throwing and swallowing at some point doesn't sound that bad, as long > as the problem is visible somewhere. Logback pretty mich logs on > STDERR or STDOUT only as well. > Yes, error handling and/or callbacks to notify the user. There are certain situations where there isn't much useful information available unless you're looking at STDERR, and even sometimes that information is pretty useless. For example, if you try to use the DOMConfigurator and the file isn't found, the only way for you to tell that something went wrong is to view the output of the process; this should probably return a bool or something to indicate that the configuration was successful or not. And then there's the incredibly unhelpful error message of "please initialize the log4cxx system properly" which should probably print out a bit more as to what it tried to do and why it failed. -Robert Middleton
Re: [log4cxx] JIRA Updates and next release?
> Just a datapoint: Debian 11 ("bookworm") will got to the first stage of freeze
> [1] on January 12th, 2023. I guess 0.13.1 will be ABI compatible, so a release
> end of this year should work. (As such changes would be allowed until February
> 12th, aka Soft-Freeze.)
> If SONAME needs to be bumped, it could get though to get it into bookworm, as
> then the January 12th deadline becomes effective for log4cxx.
Just to note: the ABI check on gitlab currently fails, but that's
because of a removal of a private static member. According to the KDE
documentation[1], that's fine to do so it would not require an SONAME
bump.
[1]: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
-Robert Middleton
Re: [log4cxx] JIRA Updates and next release?
Guten Tag Robert Middleton, am Samstag, 24. September 2022 um 15:56 schrieben Sie: > Thanks to Steven Webb's efforts, a number of long-standing JIRA issues > have now been fixed - thank you very much! +1 :-) > * Having better error reporting - many exceptions that are thrown are > basically swallowed and just print out to stderr at the moment. Come > to think of it, do we even want exceptions? It seems like a bad idea > for the logging framework to throw exceptions What else do you have in mind, some error handlers and callbacks? Throwing and swallowing at some point doesn't sound that bad, as long as the problem is visible somewhere. Logback pretty mich logs on STDERR or STDOUT only as well. > Because of the above, I'm inclined to do an 0.13.1 release before the > end of the year and wait a bit on the next major version before we're > comfortable with it. Does anybody have any thoughts? Sounds reasonable to me. Mit freundlichen Grüßen Thorsten Schöning -- AM-SoFT IT-Service - Bitstore Hameln GmbH Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK E-Mail: thorsten.schoen...@am-soft.de Web:http://www.AM-SoFT.de/ Tel: +49 5151- 9468- 0 Tel: +49 5151- 9468-55 Mobil: +49 178-8 9468-04 AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. Mit freundlichen Grüßen, Thorsten Schöning Telefon: +49 5151 9468-55 Fax: E-Mail: tschoen...@am-soft.de AM-Soft IT-Service - Bitstore Hameln GmbH Brandenburger Straße 7c 31789 Hameln Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist ausschliesslich für den Adressaten bestimmt. Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im Vertrauen auf erlangte Information untersagt. This e-mail may contain confidential and/or privileged information and is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Hinweise zum Datenschutz: bitstore.group/datenschutz
Re: [log4cxx] JIRA Updates and next release?
On Sat, Sep 24, 2022 at 09:56:50AM -0400, Robert Middleton wrote:
> Because of the above, I'm inclined to do an 0.13.1 release before the
> end of the year and wait a bit on the next major version before we're
> comfortable with it. Does anybody have any thoughts?
Just a datapoint: Debian 11 ("bookworm") will got to the first stage of freeze
[1] on January 12th, 2023. I guess 0.13.1 will be ABI compatible, so a release
end of this year should work. (As such changes would be allowed until February
12th, aka Soft-Freeze.)
If SONAME needs to be bumped, it could get though to get it into bookworm, as
then the January 12th deadline becomes effective for log4cxx.
[1] https://release.debian.org/bookworm/freeze_policy.html
Cheers,
--
tobi
signature.asc
Description: PGP signature
[log4cxx] JIRA Updates and next release?
Thanks to Steven Webb's efforts, a number of long-standing JIRA issues have now been fixed - thank you very much! I've gone through JIRA and marked those issues as resolved at this point. This means that there are only ~9 issues left in JIRA(LOGCXX-532 can probably be closed at this point - I'm fairly certain this is invoking undefined behavior that we just can't fix while still keeping the same features). The remaining issues shouldn't involve heavy refactoring at all. This brings up the question as to what/when should the next release be? We can do an 0.13.1 to fix a handful of issues in master that have been reported, or we could do the next release as a major release(I've been calling it 1.0.0). I think there's still work that needs to be done before we do a 1.0.0, including(but not limited to): * Making sure the API is clear and stable * Making sure the ABI is stable(this should be accomplished at this point, but I want to add some reserved fields to LocationInfo incase we ever need to expand it * Any other performance improvements that we can make. If we can automate some of these performance tests, that would be great as well. * Having better error reporting - many exceptions that are thrown are basically swallowed and just print out to stderr at the moment. Come to think of it, do we even want exceptions? It seems like a bad idea for the logging framework to throw exceptions Because of the above, I'm inclined to do an 0.13.1 release before the end of the year and wait a bit on the next major version before we're comfortable with it. Does anybody have any thoughts? -Robert Middleton
