println!("Let's talk about logging")

[bobmcwhirter]

Let's take a moment and think about logging. I understand the irony of this, given I'm Mr. println!.

I think certainly INFO/WARN/ERROR have their place, but we should use them to express information relevant to operators of the system. The admin who might check logs or dig around in splunk.

For things like "this SBOM is bad", we need to surface that to the UI somehow, as the SRE operating the system probably won't care.

For our purposes, DEBUG/TRACE can exist for "this SBOM is bad" sorta thing, generally suppressed.

Yeah? No?

[jcrossley3]

I understand the irony of this, given I'm Mr. println!.

🤣

[helio-frota]

yes 👍

[JimFuller-RedHat]

yes - though we could identify where our data model is 'slightly surprising' (maybe this is already known) - in terms of data quality or where we have made implicit assumptions - so far have identified the following:

• some SBOM contain packages with relationships where packages have no pURL (eg. cpe)
• deps/co-constraints between import datasets
• different SBOM usage conventions (ex. quarkus-bom)

FWIW I had inserted log::info!() mainly as a cheap data score ... there is enough data variation (ex. in SBOM spec) that upon ingestion we discover places where we can tighten data model - we could implement some data scoring to verify data quality of ingested data and discover any gaps. Even better if such data scoring is surfaced to the right users who can do something about it.

[ctron]

I agree and I think this relates to #756

[JimFuller-RedHat]

and (for data aspects) also maybe #453