On 02/11/2014 04:49 AM, Kinkie wrote:
> During recent discussion on IRC it was found out that there are not
> that many big patches queued for landing to trunk; it may be a good
> moment to rework more aggressively at least part of the debugs()
> statements.
> I would like us to get a consensus on this,
If you are asking about specific API/design changes rather than just the
fact that now is a good time to do them, then I suggest that we attack
the problem simultaneously from several different angles:
1. "Admin messages" or "default logging" (admins need this):
1a. What kind of info should be logged to syslog by default.
1b. What kind of info should be logged to cache.log by default.
1c. How to allow admins to selectively control syslog and
cache.log messages when Squid defaults do not work well.
1d. How to make admin message text uniform and stable,
to allow for better automation and documentation.
1e. How to document admin messages.
2. "Debugging" (support folks and developers need this):
2a. How to improve selective control of debugging volume and scope.
2b. How to enable/disable debugging based on rare condition(s).
2c. How to fully debug specific transactions or events.
2d. How to decrease noise and increase usefulness of debugging logs.
3. Writing debugging code (developers need this):
3a. How to make it easier to write good debugging statements.
3b. How to verify that a debugs() call complies with the new rules.
3c. How to keep default logging overheads low while addressing #1.
3d. How to lower performance overheads of debugging while addressing #2.
There is significant overlap within each section and even between the
three sections, of course. That is one of the reasons why I think a
comprehensive solution is needed here as opposed to small incremental
changes. Another reason to push for a comprehensive solution is the
amount of widespread code changes most significant improvements ought to
trigger.
I am sure all of us have specific suggestions/ideas for at least some of
the above areas, but I wanted to propose the above skeleton framework to
better structure the initial debate. Once we settle on the overall
goals/scope/structure of this project, we should probably document our
agreement on the wiki and start accumulating specific suggestions/ideas
there.
> and define some subtrees
> where work is being done and which should thus not be touched now
> because they're being worked on (e.g. the parser-ng work)
The only large pending Factory patch that I am aware of is ftp-gw. I am
pretty sure that by the time debug-ng design is agreed upon and
implemented, the native FTP code will be submitted for review and,
hopefully, committed -- we just need to finish reshuffling the
files/class as agreed previously on squid-dev...
HTH,
Alex.
