Future development of CrashRpt

[jowr]

Dear all
(@AndreasSchoenle, @olegkrivtsov, @qbprog, @TigranAnchorfree, @chsoft-ag, @p-softway, @rversteegen, @Tomash667, @martysama0134, @davidwed, @cameni, @liumazi, @CruiseYoung)

I have invited all of you to join this organization because you it looks like you are using crashrpt or have contributed to it.

In my opinion, it is a shame that this useful piece of software is not maintained in a structured way and I hope that this organization can help with that.

Feel free to ignore the invite if you are not interested.

... but if you are interested - please share your thoughts regarding this group and future development.

Thank you and sorry for bothering you.

[qbprog]

Dear Jorrit, I used crashrpt in the past, but not using it anymore. The most important missing feature was an aggregating app or server that helped to actually check and catalog bug reports and that worked in 64 bits. Feel free to fork my repo copy, I'll join the organization but unlikely will contribute to it. Thanks! Thomas (qbprog) Il ven 8 gen 2021, 09:02 Jorrit Wronski <notifications@github.com> ha scritto:

…

Dear all ***@***.*** <https://github.com/AndreasSchoenle>, @olegkrivtsov <https://github.com/olegkrivtsov>, @qbprog <https://github.com/QbProg>, @TigranAnchorfree <https://github.com/TigranAnchorfree>, @chsoft-ag <https://github.com/chsoft-ag>, @p-softway <https://github.com/p-softway>, @rversteegen <https://github.com/rversteegen>, @Tomash667 <https://github.com/Tomash667>, @martysama0134 <https://github.com/martysama0134>, @davidwed <https://github.com/davidwed>, @cameni <https://github.com/cameni>, @liumazi <https://github.com/liumazi>, @CruiseYoung <https://github.com/CruiseYoung>) I have invited all of you to join this organization because you it looks like you are using crashrpt or have contributed to it. In my opinion, it is a shame that this useful piece of software is not maintained in a structured way and I hope that this organization can help with that. Feel free to ignore the invite if you are not interested. ... but if you are interested - please share your thoughts regarding this group and future development. Thank you and sorry for bothering you. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <CrashRpt/crashrpt2#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFEPC7KLT77KJ4ACQ6V5XLSY23Y5ANCNFSM4V2DCCPQ> .

[rversteegen]

Hello,

I'd like to see CrashRpt maintained as I expect to continue using it for many years, and could occasionally help. I have a little familiarity with the codebase.

But why fork again? There are only a small number of issues and PRs on QbProg's fork, but there's no need to drop them. I suggest @qbprog transfer the repository to this organisation, which moves over issues and PRs, creates redirects, and associates all other forks with the new CrashRpt/crashrpt2, so that people can easily find it. It's frustrating when you have to rely on Google/etc's ranking to find the maintained relevant fork of a GH repo. However it's apparently necessary to first delete this fork before transferring, and if you don't want to delete this discussion issue then you could create a dummy repo and transfer this issue there.

BTW, there's a maintained fork of the CrashFix server for CrashRpt here which seems to support running on 64-bit Windows. CrashFix could be in-scope for this org too. (CrashFix is remarkable because it implements its own .pdb reader; the only open source implementation that I could find on the internet until recently when MS finally released some code and LLVM also implemented a writer. Everyone else uses dbghelp.dll, even Mozilla's/Google's BreakPad.)

I admit I've never actually tried CrashFix. I instead wrote my own simple Python scripts using BreakPad to produce backtraces from minidumps and .pdbs and to process CrashRpt reports. No report cataloguing or anything for serious use.

[jowr]

Thanks for the feedback - I agree, moving the repo is best, but I needed a place to start the discussion, thus the fork. I have now made a dummy repo and moved the issues.

I guess I can tag @wxhere to ask whether it would be OK to move CrashFix to this organisation, too.

[wxhere]

In my branch the crash report process for 64-bit dump file has no problem. Please feel free to use.

[jowr]

@wxhere Thanks for getting back to me. Can we transfer your version here or should we make a fork?

My idea is to collect the maintained versions of CrashFix and CrashRpt at a central place. It is very difficult to find a working version of the code and my hope would be that more people become interested in using the software and ultimately have more people contributing to it.

[wxhere]

@jowr Both are OK for me. Please choose for your convenient. Current version just meets my need. It's a good idea to let more people contribution to this project.

[qbprog]

Ok I will change the ownership or the repo to the organization this night when I'll get home! Thomas Il ven 8 gen 2021, 12:52 wxhere <notifications@github.com> ha scritto:

…

@jowr <https://github.com/jowr> Both are OK for me. Please choose for your convenient. Current version just meets my need. It's a good idea to let more people contribution to this project. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFEPC47V2ZTARVFXQUWFA3SY3WWDANCNFSM4V2J5CRQ> .

[qbprog]

Done :) Il giorno ven 8 gen 2021 alle ore 14:07 Thomas Laguzzi <tholag@gmail.com> ha scritto:

…

Ok I will change the ownership or the repo to the organization this night when I'll get home! Thomas Il ven 8 gen 2021, 12:52 wxhere ***@***.***> ha scritto: > @jowr <https://github.com/jowr> Both are OK for me. Please choose for > your convenient. Current version just meets my need. It's a good idea to > let more people contribution to this project. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAFEPC47V2ZTARVFXQUWFA3SY3WWDANCNFSM4V2J5CRQ> > . >

We're using CrashRpt in several of our MFC applications, and would like to continue using it for the forseeable future.

I started work on upgrading the 3rd party libraries and modified the code to compile with /std:c++17 and /permissive- last year for use in our software, but appear to have broken a few things I need to fix before updating the pull request.

I had raised the CMake version requirement as well, which conflicted with the AppVeyor VS2013 images. Which brings me to the question, how far back should we aim to keep compatibility for both the build system and compilers?