-
Notifications
You must be signed in to change notification settings - Fork 294
Kotlin Developer Meeting
Sebastian Schuberth edited this page Jun 3, 2024
·
108 revisions
This page hosts the agenda of Kotlin / deeply technical topics to be discussed by the core developers in a smaller round than the Community Meeting. If you want to contribute and have concrete technical questions, please ping us on Slack to get invited to the meeting.
- Separate applying curations from analysis / apply curations for all package managers after all analyses finished
- Avoid the need to individually filter out blank licenses or blank authors by implementing this as post-processing for all package managers.
- Code style: Discuss nesting function inside functions. I hope we may end-up with a rule when it's ok / not ok to do.
- Align on an approach of where plugin options should be parsed, see: https://github.com/oss-review-toolkit/ort/pull/7673#discussion_r1354273339
- Should we support different configurations for the same scanner or different matchers for different storages? (https://github.com/oss-review-toolkit/ort/pull/7673#discussion_r1354338264)
- Decide which content should stay in the README as most of it is currently duplicated in the docs.
- Feedback for https://github.com/oss-review-toolkit/ort-config/pull/186.
- Consolidate scan storages: https://github.com/oss-review-toolkit/ort/issues/8721
- Continue refinement.
- Sorted issues from oldest to newest, stopped at https://github.com/oss-review-toolkit/ort/issues/4395.
- Used for backlog grooming ("Closed as part of backlog grooming. Feel free to comment if you would like to contribute to this.")
- Sorted issues from oldest to newest, stopped at https://github.com/oss-review-toolkit/ort/issues/3904.
- Used for backlog grooming ("Closed as part of backlog grooming. Feel free to comment if you would like to contribute to this.")
- Sorted issues from oldest to newest, stopped at https://github.com/oss-review-toolkit/ort/issues/3085.
- Heads up: More Cargo refactoring PRs upcoming to solve https://github.com/oss-review-toolkit/ort/issues/8480.
- Martin has ticket in sprint to continue working on solving Docker "race-condition" issues.
- Proceed with https://github.com/oss-review-toolkit/ort/pull/8152.
- Do we finally want to officially support analyzing projects that are not under version control?
- Scanner API improvements
- Teach
scanPackage
about the configuredsourceCodeOrigins
. - Make the global scanner configuration accessible from scanner implementations.
- Teach
- Remove the SpdxExpression.licenses() function as it makes it too easy to do "dangerous" things?
- Replace the
ort-config
'scuration
project with a script-based solution? - Allow key / value pair as license categories with arbitrary values, see this.
- Discuss guidelines for
ort-config
contributions - Discuss https://github.com/oss-review-toolkit/ort/issues/7921, in particular
- Discuss how we could approach: https://github.com/oss-review-toolkit/ort/issues/7921
- Merge https://github.com/oss-review-toolkit/ort/pull/7853 despite theoretical Docker image issues?
- Don't let https://github.com/oss-review-toolkit/ort/pull/7888 linger around for too long.
- Continue https://github.com/oss-review-toolkit/ort/pull/7697.
- Let scanner wrapper implementations know what packages their have scanned in case of "monorepos".
- Where to apply default values for advisor configuration?
-
Align
create(options: Options)
implementations. - Get rid of double
config
nesting in ORT results for advisor / scanner configuration?- We should try to avoid constructs like
val frontendUrl = ortResult.scanner?.config?.config?.get("DOS")?.options?.get("frontendUrl")
, maybe by introducing a helper extension function (as a smooth transition to aninterface
-based API).
- We should try to avoid constructs like
- Consider replacing
SourceCodeOrigin
withList<KnownProvenance>
.- No, probably better to separate configuration names from class hierarchies.
- Discussion about Package manager implementations to expose the types of packages they create as part of the API.
- Maintain
orthw
andhelper-cli
in a single repo?
- Discuss supplier / organization information.
- How to proceed with VCS location duplicates?
- How to proceed with NuGet namespace generation?
- What should be the first SemVer of ORT (1.0.0 vs. 0.0.1)? Any particular commit to tag?
- Go for "1.0.0", tag a recent commit, like the last one from the "release notes" in the last Community Meeting
- How to proceed with unit test failure in https://github.com/oss-review-toolkit/ort/pull/7397 due to conditional ScanCode CLI options?
- Discuss command to create a "flat" analyzer result: https://github.com/oss-review-toolkit/ort/pull/7305
- Heads up for https://github.com/oss-review-toolkit/ort/pull/7331; basically no objections, but send notice to HERE who might be affected via license curations.
- Can https://github.com/oss-review-toolkit/ort/issues/5681 be closed?
- Review PRs that migrate scanner results parsers to kotlinx-serialization
- Consolidate the
FileStorage
andProvenanceFileStorage
interfaces (null
vs exception semantics)- Probably becomes void with https://github.com/oss-review-toolkit/ort/pull/7292
- Implementing snippet choice
-
New detected licenses appears for SPDX project with submodule
- See https://github.com/oss-review-toolkit/ort/issues/7231#issuecomment-1629577276 for a summary of the issue and the proposed solution.
- Use https://github.com/kopykat-kt/kopykat? -> No general objections.
- Where to put extension functions? https://github.com/oss-review-toolkit/ort/pull/7180#discussion_r1238376009
- No obvious single rule, continue to decide case by case.
- Maybe try to group extension function by purpose, like already done in
GradleModelExtensions.kt
. - Probably avoid putting arbitrary extension functions into a single file, but rather put code into an existing
Utils.kt
.
- Should we explicitly return empty vulnerabilities? https://github.com/oss-review-toolkit/ort/pull/7196#discussion_r1241260223
- https://github.com/oss-review-toolkit/ort/pull/7129
- https://github.com/oss-review-toolkit/ort/pull/7127#discussion_r1229177619
- Try to switch to the legacy Docker again in order to work around the current disk space issues in the functional tests.
- Ideas for an Amazon S3-based (scan) storage implementation
- Probably requires code clean-ups first
- Configure storages only once
- https://github.com/oss-review-toolkit/ort/issues/6603
- Probably requires code clean-ups first
- CI fails due to insufficient disk space for Docker runs
- Review of
- https://github.com/oss-review-toolkit/ort/pull/7068 -> @sschuberth
- https://github.com/oss-review-toolkit/ort/pull/7078 -> @mnonnenmacher
- Style:
fromUrl()
vsforUrl()
-> Makes sense to have the differentiation - Serialize resolved curation providers with empty curations? https://github.com/oss-review-toolkit/ort/blob/c14dee77330585cbcc41ce62a43d9e3a85ada07c/model/src/main/kotlin/ResolvedConfiguration.kt#L84 -> Keep them for explicitness
- Snippet scanner model changes (https://github.com/oss-review-toolkit/ort/pull/6791)
- ORT Result API / abstraction
- Dependency Tree vs. Graph (https://github.com/oss-review-toolkit/ort/issues/3825)
- New GoMod issue to look at.
- How to move forward with (configurable advisor plugins)[https://github.com/oss-review-toolkit/ort/pull/6613]?
- Maven caching needs fixing
- Consider changes to
init.gradle
- Do not cache remote artifacts for unknown extensions
- Consider changes to
- Allow project / package "duplicates" with the same VCS location
- Allow to limit scan storage providers to packages (not projects)
- Make scan storage providers take an "entitity" enum similar to like the
ScannerCommand
used to
- Make scan storage providers take an "entitity" enum similar to like the
- How to proceed with failing CI in https://github.com/oss-review-toolkit/ort/pull/6489?
- Maven artifact caching issues were found and fixed
- Give curation providers access to more metadata than just the package's
Identifier
: https://github.com/oss-review-toolkit/ort/pull/6387 - Agree on how to fix https://github.com/oss-review-toolkit/ort/issues/3289.
- Separating & Re-applying curations for specific providers (see this comment)
- Automated releases
- Enable conventional commits (via https://github.com/conventional-changelog/commitlint)
- Discuss curation provider configuration (https://github.com/oss-review-toolkit/ort/pull/6308)
- Stop using a
SortedSet
inProjectAnalyzerResult
(https://github.com/oss-review-toolkit/ort/pull/6244)
- Release strategy
- Decide for a module that can be moved to an independent repository for testing release automation.
- Try out https://github.com/renovatebot/renovate
- Should we do extract conventional namespaces for NuGet?
- Tendency yes, but probably use al but last component for namespace.
- Discuss how dependency injection with Koin looks like
- Should we share all of
OrtConfiguration
or only / also tool-specific config classes?
- Should we share all of
- Ok to merge https://github.com/oss-review-toolkit/ort/pull/6030?
- Yes
- Poll about handling Copyright statements without owner as unprocessed.
- Clarify how Copyright statements without owners should legally be handled.
- Warn if no
provenanceStorage
is configured?- Maybe also warn / hint about local storages in general?
- More reviews from Bosch side needed.
- Noted.
______________________________
/ \_______ \__ ___/ The OSS Review Toolkit, version 1.0.0.
| | | | _/ | |
| | | | | \ | | Running 'wiki' as 'ort' under Java on GitHub
\________/ |____|___/ |____| with a lot of CPUs and a maximum amount of memory.