Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Should we partition VLOGs into multiple levels (user-debugging and developer-debugging) #6385

Open
theopolis opened this issue Apr 9, 2020 · 1 comment
Open

Should we partition VLOGs into multiple levels (user-debugging and developer-debugging) #6385

theopolis opened this issue Apr 9, 2020 · 1 comment
Labels
logging question

Comments

@theopolis
Copy link
Member

This is intended to continue the discussion from: #6369

The first question is, who do we consider the audience for VLOG(1) logs and should there be multiple audiences? A lot of projects have the concept of VLOG(1) and DEBUG where DEBUG may only be turned on for debug-builds.

The problem this is attempting to address is minor but important, IMO several existing logs are very technical and contain obscure information.

One potential solution is to introduce a --debug that enables VLOG(2).
@theopolis theopolis changed the title Should we partition INFO logs into multiple levels (user-debugging and developer-debugging) Should we partition VLOGs into multiple levels (user-debugging and developer-debugging) Apr 9, 2020
@theopolis theopolis mentioned this issue Apr 9, 2020
Merged
@directionless
Copy link
Member

Thinking about other software I've used...

  • Unless there's a deep performance issue, I don't think debug logs should require compile time options
  • I've commonly seen multiple levels of logs.
  • sometimes linear, sometimes bitmask
  • No unification on names: debug, verbosity, trace
  • I am tentatively more in favor of something leveled (linear or bit field) than having different cli options. (Eg: is rather -v=2 or -v=255 than -v -d)

I think we should think about audiences, or subsystems, and probably the rest will follow.

  • normal usage, should be very quiet
  • verbose?
  • table developers?
  • big dump for bug reporting?
  • query planning?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
logging question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@directionless @theopolis @mike-myers-tob