- 
                Notifications
    
You must be signed in to change notification settings  - Fork 356
 
Kotlin Developer Meeting
        Sebastian Schuberth edited this page Sep 2, 2025 
        ·
        234 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.
 - 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)
 - Proposed enhance of Contribution rules: Clearly separate upstream data models and its parsing from any other logic, such as the mapping to
ORT's model. Disallow the mixing to reduce maintenance cost. 
- Use immutable releases?
- Tendency is yes, need to get a better understanding about which tags are protected.
 
 - Externalize test projects?
- Would solve the issue for people running e.g. Scorecards against our repo.
 - Potentially avoids patching of VCS info.
 
 - Should we remove 
toolVersionsfromEnvironment? - What more 
LicenseFactProviders to add? - How to proceed with the Gradle variant tracking PR?
 
- Discuss potential problems with 
deleteOnExit(). - Reconsider Dependency Injection via Koin for ORT's configuration.
 - Experiments with Flox.
 - python-inspector again:
- no response for a week: https://github.com/aboutcode-org/python-inspector/pull/237
 - no response for 3 weeks: https://github.com/aboutcode-org/python-inspector/issues/234
 - no response for 7 weeks: https://github.com/aboutcode-org/python-inspector/issues/229
 
 
- Ease configuring reporters to include verbatim instead of "normalized" license texts.
- Related:
 - Idea: Maybe enrich SBOMs (a bit similar to Parlay) with re-extracted license texts.
 
 - Consider using the GitHub API (for some ecosystems) to get "declared" licenses.
- Also see this Pub / Flutter issue.
 - How does 
pub.devthat the packaged / includedLICENSEfile contains e.g. MIT text? 
 
- Decide on making simple license mappings more strict.
 
- Make a decision regarding license text/data providers.
- https://github.com/oss-review-toolkit/ort/issues/9620
 - https://github.com/oss-review-toolkit/ort/pull/10479
 - Conclusion:
- Name for provider: 
LicenseFactProvider - @mnonnenmacher will provide an updated example that returns LicenseFact objects instead of only strings to prepare for adding more properties later.
 
 - Name for provider: 
 
 - Make a decision regarding includes.
- https://github.com/oss-review-toolkit/ort/issues/10347
 - Conclusion: All participants agree that only adding includes as described in https://github.com/oss-review-toolkit/ort/issues/10347#issuecomment-2975312451 is sufficient for now.
 
 - Make a decision regarding 
ScannerRunissues. 
- Discuss a workaround for https://github.com/oss-review-toolkit/ort/issues/6711.
 
- How to implement AI-powered Copyright filtering? (in OCCTET context)
- Generate a 
copyright-garbage.ymlfile? Still needsscan-result.ymlas the input.- This is the way to go for now.
 
 - Rewrite 
scan-result.ymlwith Copyrights filtered out? - Create a plugin interface for Copyright garbage filters?
 
 - Generate a 
 - Agreement to aim for a strict split between data classes that resemble serialization models and mappings to ORT data models
- A good example are the Node PM's 
ModuleInfo.ktfiles- Only one top-level data class with no member functions
 - No other top-level functions than those needed for deserialization
 - No ORT-specific code or imports
 
 - Probably add this to the contribution or development guide
 - Additional detekt / Konsist checks maybe
 
 - A good example are the Node PM's 
 
- Plugin id / display name refactorings
 - Cleanup up examples vs config in 
ortandort-configrepos. Also see: 
- Remove the "versions" plugin?
- Maybe try https://github.com/bishiboosh/caupain for local usage instead?
 
 - Discuss using LicenseLynx for Java.
 
- Discuss Exclude binary license files to prevent reporter hang.
- Comments added to PR.
 
 - Consider removing on-disk-caches in favor of only in-memory-caches (Yarn, Maven).
- Try with in-memory cache only for Yarn to reduce usage of old DiskLru cache; eventually re-implement on-disk caching with other means if there are performance issues.
 
 - Rename 
helper-clitocli-helperto group withcli.- Yes.
 
 
- What should we do about the Python Inspector?
 - Options to solve issue with storing failed scan ersults.
 
- How to proceed with the "Project" suffix?
 - Discuss reporter types.
 
- Agree on way forwards for package configuration version ranges https://github.com/oss-review-toolkit/ort/issues/9918
 - Add new SPDX reporter which uses the SPDX java library.
- at first: Produce similar output to the existing reporter
 - then: Produce also SPDX v2.3
 - Remove existing reporter later on if the new one is considered a replacement.
 
 
- Do we want to merge the ORT Result Schema Reporter?
- Basically yes, but maybe migrate to a top-level option similar to clikt's built-in 
--generate-completion. 
 - Basically yes, but maybe migrate to a top-level option similar to clikt's built-in 
 
- Plugin questions (@mnonnenmacher)
- Should plugin constructors be internal to force use of the factory? -> yes
 - Should plugin descriptors move from the constructor to overrides inside the class? -> no
 
 - Issue label vs types vs. templates (@sschuberth)
- Enhancement vs. new feature
 
 
- Publishing of daily / nightly ORT snapshots.
- Dropped the idea in favor of local builds.
 
 - PR grooming:
 
- Agreed to disclose if support requests (Slack, GitHub) are coming from a party any of us is getting paid for.
 - PR grooming:
- 
https://github.com/oss-review-toolkit/ort/pull/9487
- @sschuberth replied, will move forward.
 
 
 - 
https://github.com/oss-review-toolkit/ort/pull/9487
 
- Discuss a License Text Provider API.
 - Avoid the need for deep copies by allowing 
varin model data classes. - BlackDuck integration:
- Decide how to inject BlackDuck component curations (specify 
externalIdorpurl) - Options for doing funTest against non-public instance
 
 - Decide how to inject BlackDuck component curations (specify 
 - Discuss specific open PR (@tsteenbe) - should we do PR grooming?
 
- Used for backlog grooming ("Closed as part of backlog grooming. Feel free to comment if you would like to contribute to this.")
- Finished!
 
 
- 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 page 8, https://github.com/oss-review-toolkit/ort/issues/8278.
 
 
- Where to add the "Project" suffix in https://github.com/oss-review-toolkit/ort/pull/9392?
 - Data model for https://github.com/oss-review-toolkit/ort/issues/9409.
 
- Proceed with https://github.com/oss-review-toolkit/ort/pull/9301.
 - Project vs package duplicates, which one to remove / keep?
 
- 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 page 6, https://github.com/oss-review-toolkit/ort/issues/7238.
 
 
- Setting SPDX's 
licenseDeclarede.g. for Go dependencies that have no metadata?- Yes, based on 
RootLicenseMatcher. - Additionally, the analyzer could query the GitHub API for "repository declared licenses" (which are actually licenses detected by Licensee).
 
 - Yes, based on 
 - Should we have a "too many scan failures" heuristic for scanners? Also see this discussion.
- Rather throw special exception from scanner implementation that generic heuristic on "client" side.
 
 - 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 page 6, https://github.com/oss-review-toolkit/ort/issues/6960.
 
 
- 
Build ORT with Java 21
- Postpone by at least one week to not cause migration efforts for this week's release, which contains important Bazel changes.
 
 - Remove SPDX document file analyzer in favor of making the package list helper-cli an analyzer.
- No, still required by Bosch. Better do another implementation based on the new SPDX Java library, similar to a new SPDX reporter.
 - Also will be required by BitBake support.
 
 - Cleanup of teams.
- Proposal: Consolidate "Committers", "Contributes" and "core-devs" to just "devs".
 
 
- Discuss how to best represent projects which are part of a "workspace" in the analyzer result. As Project or as Package. See also node managers.
 
- New API to download JDKs.
- Expose version (and name) property to select JDK.
 
 - Remove NexusIQ.
- 90 day deprecation notice first, ask in community meeting.
 
 - Work to maintain CVSS vectors.
- Split severity into score and vector.
 
 
- Update on new plugin API: https://github.com/oss-review-toolkit/ort/pull/9002
 - 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 page 5, https://github.com/oss-review-toolkit/ort/issues/6668.
 
 
- Propagation of MDC context: https://github.com/oss-review-toolkit/ort/pull/9006
 - New plugin API: https://github.com/oss-review-toolkit/ort/pull/9002
 
- Better documents requirements / conventions for 
commentfields inort-configcurations.- Maybe introduce a 
reasonenum (similar to*ResolutionReason, with a default value ofOTHERorUNSPECIFIED) and an optionalrelated_urlsarray for more structure. 
 - Maybe introduce a 
 - Agreed to drop support for old ScanCode versions.
 - 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 page 5, https://github.com/oss-review-toolkit/ort/issues/6186.
 
 
- Skipped due to general unavailability of participants.
 
- 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 page 4, https://github.com/oss-review-toolkit/ort/issues/5520.
 
 
- 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 page 4, https://github.com/oss-review-toolkit/ort/issues/5081.
 
 
- Feedback for https://github.com/oss-review-toolkit/ort/pull/8691
 - ...and https://github.com/oss-review-toolkit/ort/pull/8730
 - Contributing DOS package configuration provider and DOS scanner wrapper
 
- Priority of package configuration provider.
 - Dynamically install the correct Node version.
 - Black Duck as advisor / vulnerability provider
 
- 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 
scanPackageabout 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'scurationproject with a script-based solution? - Allow key / value pair as license categories with arbitrary values, see this.
 
- Discuss guidelines for 
ort-configcontributions - 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 
confignesting 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 
SourceCodeOriginwithList<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 
orthwandhelper-cliin 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.
 
- Review PRs that migrate scanner results parsers to kotlinx-serialization
 - Consolidate the 
FileStorageandProvenanceFileStorageinterfaces (nullvs 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 
ScannerCommandused 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 
SortedSetinProjectAnalyzerResult(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 
OrtConfigurationor 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 
provenanceStorageis 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.