You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This won't actually be a review workflow proper but would just be a helpful guide when reviewing/looking into scans, with additions in the already present package/license explorer views. The format seems to be stable after several rounds of discussion, but still we can do this after the stable release, just in case.
Here we should have either a red bug symbol or a exclamation mark symbol in the license detections list on the left pane of the license explorer, and have a new section in the details pen on the right, which will also show the review_comments (this section would be there only if the license detection is listed is an issue). Just having this part should be enough in the short term and would be a huge help in the license detection review.
Note that is review option is enabled, the license clues also show up as todo items and they are only listed once per unique detection, so this could be even used to remove duplicate clues. (This can be a improvement later)
package issues:
There are two main types of package issues in the review, one is CANNOT_CREATE_PURL: The package data detected doesn't have enough fields to create a packageURL (required fields are type, name and version), which is a package manifest parsing/incomplete data issue. CANNOT_CREATE_TOP_LEVEL_PACKAGE: The package data detected couldn't be processed/merged into a scan-level package that is returned which is a package-assembly issue.
These are not reported currently in the package section as these are not top-level packages, so we'd have to also have these as incomplete package records in a section below the actual detected packages, similar to the license detection - license clue view.
The text was updated successfully, but these errors were encountered:
I am not clear about the intent of this feature. If it is limited to supporting use of SCWB to debug ScanCode data problems in desktop mode that probably makes sense, but we need to be careful to avoid scope creep in the direction of the deprecated Conclusions feature. Anything like Conclusions needs to be in a multi-user context (possibly SCIO) and not in a single-user desktop app.
If it is limited to supporting use of SCWB to debug ScanCode data problems in desktop mode
Yup that is it.
but we need to be careful to avoid scope creep in the direction of the deprecated Conclusions feature.
Nope, we're not going towards conclusions/some proper review system where we curate/conlude/edit the data, which should be a scancode.io feature. This is tracked in aboutcode-org/scancode.io#817. That's why I started with This won't actually be a review workflow proper. 😄
This won't actually be a
review
workflow proper but would just be a helpful guide when reviewing/looking into scans, with additions in the already present package/license explorer views. The format seems to be stable after several rounds of discussion, but still we can do this after the stable release, just in case.See aboutcode-org/scancode-toolkit#3122 (comment) for the current state of this.
There are two kinds of issues here:
Here we should have either a red bug symbol or a exclamation mark symbol in the license detections list on the left pane of the license explorer, and have a new section in the details pen on the right, which will also show the review_comments (this section would be there only if the license detection is listed is an issue). Just having this part should be enough in the short term and would be a huge help in the license detection review.
Note that is review option is enabled, the license clues also show up as todo items and they are only listed once per unique detection, so this could be even used to remove duplicate clues. (This can be a improvement later)
There are two main types of package issues in the review, one is
CANNOT_CREATE_PURL
: The package data detected doesn't have enough fields to create a packageURL (required fields are type, name and version), which is a package manifest parsing/incomplete data issue.CANNOT_CREATE_TOP_LEVEL_PACKAGE
: The package data detected couldn't be processed/merged into a scan-level package that is returned which is a package-assembly issue.These are not reported currently in the package section as these are not top-level packages, so we'd have to also have these as incomplete package records in a section below the actual detected packages, similar to the license detection - license clue view.
The text was updated successfully, but these errors were encountered: