-
Notifications
You must be signed in to change notification settings - Fork 310
Kotlin Developer Meeting
Sebastian Schuberth edited this page Nov 11, 2024
·
143 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.
- 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
licenseDeclared
e.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
comment
fields inort-config
curations.- Maybe introduce a
reason
enum (similar to*ResolutionReason
, with a default value ofOTHER
orUNSPECIFIED
) and an optionalrelated_urls
array 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
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.