Remove the logging panel as discussed

[matthiask]

Closes #1683, closes #1681, closes #1119, closes #906, closes #695.

Description

Sorry for rushing ahead. I looked at the ticket tracker again and found all those open issues that could be closed by this change. I had to do it 😅

[tim-schilling]

Love it! Though we should do what you originally suggested and replace the logging panel class with a stub class that does nothing, but logs a warning to be removed from the config. That way when someone upgrades we don't break their project.

[tim-schilling]

100% agreement with this. We should probably update the mo / po translation files with this. I forget which one is first off the top of my head.

[matthiask]

First .po (text) then .mo (compiled); you did the Transifex sync last time, I have never managed to get it working (but haven't spent much time doing it)

It's not critical since we do not have any new strings to translate though.

[tim-schilling]

Gotcha, thank you for the clarification. I do think you should regenerate the po files. The updated po files would have the logging related translated strings removed, which if we have any translators currently working, would reduce their workload. I'm pretty sure transifex will pick up the change once it's merged into automatically. I'll handle the syncing of the mo files back into the repo later.

python -m django makemessages --no-obsolete should do the trick.

[matthiask]

cd debug_toolbar && ../.tox/py310-djmain-sqlite/bin/django-admin makemessages -a --no-obsolete did it.

I pushed the change; the CI is green, let's merge it :)

[tim-schilling]

Sounds good to me!

[Shriukan33]

Thanks !

[tim-schilling]

I realized I probably should include what we actually discussed on our call.

I originally proposed changing our logging panel to no longer try to capture logs as soon as the panel was imported. Instead it would have only started monitoring when the panel was initialized. This would allow for us to keep the old version of the panel around if needed.

Matthias proposed simply disabling the panel by default. This would have reduced the number of issues created, but wouldn't actually close the issues.

Eventually we realized that we weren't sure if the logging panel even worked. Some exploratory attempts didn't show any thing. After discussing the purpose of the logging panel, we decided that because logs could be configured and monitored elsewhere (the terminal), there was less benefit in presenting the information as a part of the request in the toolbar.

Hopefully this helps us keep track of our reasoning in the future.

[matthiask]

Thanks for writing it down!

[goetzb]

Thanks for the summary - I'm surprised by this change, I liked to use the panel sometimes for quick debugging of views. I'd have preferred to at least keep it around as an optional panel that's off by default but could still be activated easily.

[matthiask]

I totally understand. For the record: The general idea of a logging panel hasn't been rejected at all and if someone were to propose adding a new logging panel without the issues of the old one we'd certainly consider it and quite certainly merge it!