feat: Introduce a way to suppress violations #119

softius · 2024-04-22T09:45:04Z

Summary

Suppress existing violations, so that they are not being reported in subsequent runs. It allows developers to enable one or more lint rules and be notified only when new violations show up.

Related Issues

Change Request: Introduce a system to suppress existing errors

linux-foundation-easycla · 2024-04-22T09:45:08Z

The committers listed above are authorized under a signed CLA.

✅ login: softius / name: Iacovos Constantinou (48e9d0a, 4d73750, 98779dc, 70a7c56, d5411af, ad5343d, 46cf6ae, 9e035f1, b343ddb, 4462ce6, b33e324, 42d8b95, 861f1a4, f9b3976, bff622d, b8a1cf7, a94a50d, 485f684, dc2d940, 2d4dc84, a99c456, 4fea00e, ed01be1, 566e3b9, 1a1cbba, 0c3d9a4, 78d37ab, c9a718c, f134daa, 71ee661, c005f3b)

designs/2024-baseline-support/README.md

bradzacher · 2024-04-22T12:52:47Z

designs/2024-baseline-support/README.md

+
+Furthermore, we are adding one more reason to exit with an error code (see "Maintaining a lean baseline"). This might have some negative side-effects to wrapper scripts that assume that error messages are available when that happens. We could introduce a different exit code, to differentiate between exiting due to unresolved errors or ignored errors that do not occur anymore.
+
+## Alternatives


the alternative we've introduced at Canva is that we designate specific rules as "in migration" and we only consider reports from those rules if they exist in changed files (according to git comparison against the main branch).

With this system developers must address lint errors if they touch a file but otherwise they can be ignored.

This does require integration with the relevant source control system - though we've found it works quite well.

fasttime · 2024-04-23T16:28:38Z

Thanks for the RFC @softius. Can you please sign the CLA as requested in this comment?

designs/2024-baseline-support/README.md

nzakas

Thanks for putting this together. It sound good in theory, but you haven't provided much in the way of implementation details. Please dig into the code a bit to see how this might be implemented.

designs/2024-baseline-support/README.md

nzakas · 2024-05-15T15:20:39Z

@octogonz Would really like your feedback on this based on your work on Rush Stack Bulk.

octogonz · 2024-05-15T21:38:06Z

The feature that we designed is part of @rushstack/eslint-patch. Kevin Yang summarized it in this blog post.

A key design question is how to keep bulk suppressions stable across Git merges, since they are stored separately from the associated source code. From a cursory glance, it sounds like this RFC is proposing to count the number of errors per file path. We prototyped that design, as well as a design that tracks line #'s, and also a design that tracks formatted messages ('x' is already defined.) which are more specific than rule names (no-redeclare). We also considered actually storing the suppressions in the source with a different comment syntax.

Ultimately we settled on a JSON file using a scopeId that loosely identifies regions of code (e.g. ".ExampleClass.example-method") while still being simple enough for humans to interpret without having to consult a specification. This notation is abstracted such that we can reuse the exact same scopeId syntax for tsc/tsconfig.json bulk suppressions (a related feature we're planning to release soon), even though it it is derived from the compiler AST instead of ESLint's AST.

There's probably still a lot that can be improved about our approach. However I can say that Microsoft and TikTok are using it successfully in two very large TypeScript monorepos, where style guide migrations involve hundreds of thousands of source files and megabytes of JSON. So it's worth studying even if you don't adopt it. 🙂

As far as future improvements, a feature I'd like to see is an API that enables the VS Code extension to highlight suppressed violations specially. Currently people either highlight them as normal errors (which I find confusing, since you have to run the CLI to find out whether you really need to fix it or not) or else don't highlight them at all.

@kevin-y-ang

nzakas · 2024-05-16T16:03:31Z

@octogonz thanks for the insights. I think we're past the point of adopting eslint-bulk wholesale, but would welcome your feedback on this RFC to see if there are any salient points that have been missed or problem areas you've encountered.

octogonz · 2024-05-21T19:16:26Z

thanks for the insights. I think we're past the point of adopting eslint-bulk wholesale, but would welcome your feedback on this RFC to see if there are any salient points that have been missed or problem areas you've encountered.

Agreed, the eslint-bulk tool was implemented as a monkey patch, therefore it can't be reused directly; the approach needs to be reworked in order to integrate this feature into official ESLint.

I've been really busy lately, but I'd like to help out with the RFC. Let me make some time to read through @softius's doc in more detail, then follow up with feedback.

fasttime · 2024-05-28T10:25:36Z

@softius just a reminder that there are some suggestions for you to apply. Please, let us know if you need any help.

Humni · 2024-05-29T19:48:35Z

I really support this RFC - we've been running our own baseline package (just a wrapper around eslint), which takes the same approach. We've been using this implementation on about 30+ prod projects with no complaints from our team. Hopefully, this implementation can assist with the RFC

Co-authored-by: Nicholas C. Zakas <[email protected]>

nzakas

Apologies for the delay in getting back to this. Had a lot of post-v9 work.

I think there are some helpful ideas that eslint-bulk has that we should consider here:

Using the term "suppressions" instead of "baseline" - I think this clarifies what is actually happening. While people may not understand what generating a baseline is, most will understand when something is suppressed.
A way to indicate which rules should be suppressed. For instance, if I just want to suppress "no-eval", I should be able to do that. That may mean rethinking the command line flags. So maybe --suppress-rule <ruleId> and --suppress-all for all rules?

designs/2024-baseline-support/README.md

nzakas · 2024-06-03T14:51:02Z

@Humni that's great! Do you have any specific feedback on the implementation described in this proposal? How does it compare to what you're already using?

kevin-y-ang · 2024-06-06T21:54:14Z

Hi Nicholas, thanks for checking out the eslint-bulk project!

Using the term "suppressions" instead of "baseline" - I think this clarifies what is actually happening. While people may not understand what generating a baseline is, most will understand when something is suppressed.

Other names we considered were exemptions, pardons, and legacy-suppressions.

On a semi-related note, the "baselines" feature seems to very closely resemble the already existing eslint --max-warnings flag, which might be a source of confusion if the two features are both retained.

nzakas · 2024-06-07T14:18:47Z

On a semi-related note, the "baselines" feature seems to very closely resemble the already existing eslint --max-warnings flag, which might be a source of confusion if the two features are both retained.

@kevin-y-ang I'm not sure I follow. Can you explain what you mean by this?

kevin-y-ang · 2024-06-07T22:33:00Z

At a conceptual level, both the proposed baseline feature and the --max-warnings feature set a threshold of X errors where the system will alarm if there are >X errors.

At our company, we previously used eslint . --max-warnings X to block merge requests for packages with high warning counts. I believe this was the intended use case when it was originally created?

The message essentially being conveyed here is "Okay there are already X number of ESLint warnings in this package but we won't allow any more", while the message being conveyed with the baseline feature seems to be a more granular version of this: "Okay there are already X number of ESLint errors/warnings for rule R in file F but we won't allow any more."

Anyway, it's just a similarity I see, it's not a big deal.

Humni · 2024-06-10T02:21:23Z

@Humni that's great! Do you have any specific feedback on the implementation described in this proposal? How does it compare to what you're already using?

Probably the main decision to make for this RFC which style of error matching you use. These would be:

Exact Error Line Matching
Context Error Matching
Count with Context Matching (recommended)

With our current implementation, we use the Exact Error Line Matching, which does have some short falls. It works pretty well, the vast majority of PRs don't require any rework. There are cases where if you modify a line at the top of a file though, will cause all of the existing errors to be exposed. This approach was chosen due to simplicity. For the most part this does push a project to having a smaller and smaller baseline, however it does lead to developers touching the baseline "too much" due to them not wanting to fix errors not directly related to their PR.

We're currently exploring moving to a context aware error matching, so it only comes up if the nearest 3 lines of code are modified - LuminateOne/eslint-baseline#8. This would provide a solution to the issue above, but it's not yet tested but seems like a sensible approach (if it can be done in a performant way).

I would highly recommend an error count approach the same as PHPStan (as per comments from @ondrejmirtes), as that seems to sit with the development team better.

Only other question "feature request" I would add into this is to allow for "flushing" a baseline of excess/resolved errors only (and not add any new ones). Just a QOL improvement though as it's typically easy enough to see new lines added into the diff in the baseline.

nzakas · 2024-06-10T15:04:27Z

@Humni gotcha, that's helpful. So it sounds like the current RFC, which uses error counting, is what you'd prefer. 👍

Keep in mind, too, that we generally build things incrementally. Our goal here is to get a baseline (no pun intended) of support for suppressions such that we can continue to build on top of it as feedback comes in.

nzakas · 2024-06-24T14:56:32Z

@softius are you still working on this? There is some outstanding feedback to review.

Co-authored-by: Francesco Trotta <[email protected]>

fasttime · 2024-08-20T08:59:35Z

designs/2024-baseline-support/README.md

+    /**
+     * Checks the provided suppressions against the lint results.
+     * 
+     * For each error included in `results`, checks if the error and the file are in `suppressions`.
+     *  If yes, the count is decreased by 1 and ignores the error unless the count has reached zero. 
+     * Otherwise, it keeps the error.
+     * 
+     * It returns the lint results that are not in the suppressions file,
+     * as well as the unmatched suppressions.
+     * 
+     * @param {LintResult[]} results The lint results.
+     * @param {SuppressedViolations} suppressions The suppressions.
+     * @returns {{
+     *   results: LintResult[],
+     *   unmatched: SuppressedViolations
+     * }}
+     */
+    applySuppressions(results, suppressions)


Thanks for the update. Maybe I'm misunderstanding something, so bear with me. It would be helpful if you could add a draft implementation to show how this function will work.

To clarify, this is an example I would like to understand. Suppose you have a file test.js where the no-undef rule would normally report three errors:

/* eslint no-undef: "error" */ a = b + c;

Playground link

What will the function return when the suppression file specifies a count of 2? This is what the arguments will look like:

const results = [{ filePath: '/my-project/test.js', messages: [{ ruleId: 'no-undef', severity: 2, message: "'a' is not defined.", line: 3, column: 1, nodeType: 'Identifier', messageId: 'undef', endLine: 3, endColumn: 2 }, { ruleId: 'no-undef', severity: 2, message: "'b' is not defined.", line: 3, column: 5, nodeType: 'Identifier', messageId: 'undef', endLine: 3, endColumn: 6 }, { ruleId: 'no-undef', severity: 2, message: "'c' is not defined.", line: 3, column: 9, nodeType: 'Identifier', messageId: 'undef', endLine: 3, endColumn: 10 }], suppressedMessages: [], errorCount: 3, fatalErrorCount: 0, warningCount: 0, fixableErrorCount: 0, fixableWarningCount: 0, source: '/* eslint no-undef: "error" */\n\na = b + c;\n', usedDeprecatedRules: [] }]; const suppressions = { "test.js": { "no-undef": { count: 2 } } };

You can see that the input results contains details about each error, while the suppressions are just numbers. What will the call to applySuppressions(results, suppressions) return in this case?

In that case it will return an updated copy of results and an empty object for unmatched (because all suppressions are matched).

// results const results = [{ filePath: '/my-project/test.js', messages: [ { ruleId: 'no-undef', severity: 2, message: "'c' is not defined.", line: 3, column: 9, nodeType: 'Identifier', messageId: 'undef', endLine: 3, endColumn: 10 }], suppressedMessages: [], errorCount: 1, fatalErrorCount: 0, warningCount: 0, fixableErrorCount: 0, fixableWarningCount: 0, source: '/* eslint no-undef: "error" */\n\na = b + c;\n', usedDeprecatedRules: [] }]; // unmatched {}

If I understand correctly, this means removing the first count messages with a particular rule-id from each result, where count is the suppression count. So, in the above example a and b would be suppressed but not c, because in the input result, a and b are sorted first in order of location.

I think this behavior would be very surprising to users. This means that some rule violations would be reported only for (the bottom) part of a file.

I think it would be better to report all messages unfiltered if the suppression count is less than the number of messages, because in that situation we can't make a meaningful selection. So for each file and rule-id we should always report either all messages, or none of them.

nzakas · 2024-08-28T15:25:08Z

@eslint/eslint-tsc looking for another approval on this.

mdjermanovic · 2024-08-29T18:23:17Z

designs/2024-baseline-support/README.md

+
+### Suppressing violations of a specific rule
+
+A new option `--suppress-rule [RULE1]` will be introduced to ESLint CLI. When provided, the existing suppressions file will be updated to include any existing violation of the provided rule. The suppressions file will be created if not already exists. Note that this is option can accept an array of string values.


Suggested change

A new option `--suppress-rule [RULE1]` will be introduced to ESLint CLI. When provided, the existing suppressions file will be updated to include any existing violation of the provided rule. The suppressions file will be created if not already exists. Note that this is option can accept an array of string values.

A new option `--suppress-rule [RULE1]` will be introduced to ESLint CLI. When provided, the existing suppressions file will be updated to include any existing violation of the provided rule. The suppressions file will be created if not already exists. Note that this option can accept an array of string values.

designs/2024-baseline-support/README.md

mdjermanovic · 2024-08-29T18:38:19Z

designs/2024-baseline-support/README.md

+* The developer runs `eslint --supress-all ./src` to create the suppressions file.
+* Running `eslint ./src` reports no violations and exits with status 0.
+* After fixing a violation, the suppressions file still contains the now-resolved violation.
+* Running `eslint ./src` again reports no violations but exits with a non-zero status code, indicating the suppressions file needs updating.


In this case, will there be an error message, and what would it look like? Technically, will it be a lint message passed to the formatter along with other lint messages for the file, or a separate output?

mdjermanovic · 2024-08-29T19:16:29Z

Having a closer look at the source code, I have noticed that it messages suppressed with eslint-disable. Should we handle messages suppressed by this RFC the same way ?

That's a good question. I think it makes sense to insert lint messages suppressed by this feature into LintResult#suppressedMessages before passing lint results to the formatter. @nzakas @fasttime thoughts?

nzakas · 2024-08-29T20:22:38Z

I think it makes sense to insert lint messages suppressed by this feature into LintResult#suppressedMessages before passing lint results to the formatter

I agree. Makes sense. 👍

fasttime · 2024-08-30T07:13:58Z

I think it makes sense to insert lint messages suppressed by this feature into LintResult#suppressedMessages before passing lint results to the formatter.

Makes sense. I think that errors suppressed by the suppressions file will have no suppressions array attached to them, so tools should be able to tell them apart from errors suppressed per eslint-disable directive because of that.

nzakas · 2024-09-11T14:40:08Z

@softius I think all that's left is to update the RFC to mention suppressedMessages (see previous three comments). Can you take a look?

fasttime · 2024-10-18T16:07:11Z

@softius Any way we can help you to finish the work on this RFC?

softius · 2024-10-31T06:04:06Z

@fasttime @nzakas that is clear, I will do one more iteration to see how messages can be passed to suppressedMessages and let you know for any questions.

Co-authored-by: Milos Djermanovic <[email protected]>

softius · 2024-10-31T06:44:46Z

RFC updated to indicate that matched messages will be moved from LintResult#messages to LintResult#suppressedMessages .

nzakas

Overall LGTM. Would like @mdjermanovic and @fasttime to verify before merging.

Thanks so much for all of your work and patience.

mdjermanovic · 2024-11-03T18:07:21Z

I think the following review comments haven't been addressed:

mdjermanovic · 2024-11-03T18:33:46Z

designs/2024-baseline-support/README.md

+2. **Match Errors Against Suppressions**
+  * For each error, check if the error and the file are in the suppressions file.
+  * If yes, decrease count, in memory, by 1 and move the message to `LintResult#suppressedMessages` unless count is zero.
+  * If no, keep the error.


(related to the discussion under #119 (comment))

For one file and one rule, I think either all or none of the messages should be moved to suppressedMessages. By this algorithm, when the number of error messages is greater than the number stored in the suppressions file, some would be moved to suppressedMessages while some would stay in messages.

mdjermanovic · 2024-11-03T19:18:27Z

designs/2024-baseline-support/README.md

+
+The suggested solution always compares against the existing suppressions file, typically `.eslint-suppressions.json`, unless `--suppressions-location` is specified.  This makes it easier for existing and new projects to adopt this feature without the need to adjust scripts in `package.json` and CI/CD workflows. 
+
+To perform the comparison, we will go through each result and message from `ESLint.lintFiles`, checking each error `(severity == 2)` against the suppressions file. By design, we ignore warnings since they don't cause eslint to exit with an error code and serve a different purpose. If the file and rule are listed in the suppressions file, we can move the message to `LintResult#suppressedMessages` and ignore the result message.


SuppressedLintMessage should have an additional property suppressions. We should specify what value it will have in this case. I think it can be:

suppressions: [{ kind: "file", justification: "" }]

@mdjermanovic can you please clarify what would be the purpose of this new property?

It describes the reason why the lint message is suppressed. It's a mandatory property in SuppressedLintMessage type (objects in LintResult#suppressedMessages). Without it, integrations and formatters that use LintResult#suppressedMessages could break.

Thanks @mdjermanovic . I was under the impression that you were referring to a new property for some reason. That is clear now.

nzakas · 2024-11-04T16:09:58Z

@mdjermanovic as it seems like we are getting down to fine-tuning some details, can we move this to Final Commenting?

mdjermanovic

I'm fine with moving to Final Commenting with a note that when the number of errors exceeds the allowed number, all errors should be reported, as described in #119 (comment).

fasttime · 2024-11-05T06:14:26Z

designs/2024-baseline-support/README.md

+  * If `--prune-suppressions` is passed, take the updated suppressions from memory to check which suppressions are left.
+  * For each suppression left, update the suppressions file by either reducing the count or removing the suppression.
+4. **Report and exit**
+  * Exit with a non-zero status if there are unmatched suppressions, optionally listing them in verbose mode.


By verbose mode we probably mean when the --debug flag is passed on the command line.

fasttime · 2024-11-05T06:21:11Z

designs/2024-baseline-support/README.md

+    /**
+     * Removes old suppressions that do not occur anymore.
+     * @returns {void}
+     */
+    prune()


I think this method needs to accept an argument with the updated count of suppressed errors per rule and per file.

fasttime · 2024-11-06T13:33:54Z

designs/2024-baseline-support/README.md

+Here is a high-level overview of the execution flow:
+
+1. **Check for Options**
+  * If both `--suppress-all` and `--suppress-rule` are passed, exit with an error (these options are mutually exclusive).


It seems that --prune-suppressions will have no effect when --suppress-all or --suppress-rule is passed. Should it be also disallowed when one of the other options is passed?

rfcs/designs/2024-baseline-support/README.md

Lines 224 to 230 in f134daa

if (options.suppressAll) {

suppressionsManager.suppressAll(results);

} else if (options.suppressRule) {

suppressionsManager.suppressByRule(results, options.suppressRule);

} else if (options.pruneSuppressions) {

suppressionsManager.prune();

}

fasttime · 2024-11-06T14:27:55Z

designs/2024-baseline-support/README.md

+        log.error("There are left suppressions that do not occur anymore. Consider re-running the command with `--prune-suppressions`.");
+        return 2;


Question: do we really want to exit without printing the lint results here?

softius added 2 commits April 22, 2024 09:06

Add RFC for baseline support

a99c456

Fix typos

f9b3976

eslint-github-bot bot added the feature label Apr 22, 2024

bradzacher reviewed Apr 22, 2024

View reviewed changes

nzakas added the Initial Commenting This RFC is in the initial feedback stage label Apr 22, 2024

ondrejmirtes reviewed Apr 24, 2024

View reviewed changes

designs/2024-baseline-support/README.md Outdated Show resolved Hide resolved

nzakas requested changes May 6, 2024

View reviewed changes

softius added 3 commits May 6, 2024 21:31

Add question about warnings

c9a718c

Convert relative to full paths

4d73750

Replace --generate-baseline with --baseline/-location

9e035f1

nzakas reviewed May 7, 2024

View reviewed changes

designs/2024-baseline-support/README.md Outdated Show resolved Hide resolved

Add more implementation details, add relative paths to CWD

ed01be1

nzakas reviewed May 10, 2024

View reviewed changes

designs/2024-baseline-support/README.md Outdated Show resolved Hide resolved

designs/2024-baseline-support/README.md Outdated Show resolved Hide resolved

Update designs/2024-baseline-support/README.md

d5411af

Co-authored-by: Nicholas C. Zakas <[email protected]>

nzakas reviewed Jun 3, 2024

View reviewed changes

designs/2024-baseline-support/README.md Outdated Show resolved Hide resolved

designs/2024-baseline-support/README.md Outdated Show resolved Hide resolved

softius and others added 2 commits August 16, 2024 17:03

Use block comments

861f1a4

Co-authored-by: Francesco Trotta <[email protected]>

More details about prune-suggestions and how the filtering works.

566e3b9

nzakas previously approved these changes Aug 16, 2024

View reviewed changes

fasttime reviewed Aug 20, 2024

View reviewed changes

mdjermanovic reviewed Aug 29, 2024

View reviewed changes

Update designs/2024-baseline-support/README.md

78d37ab

Co-authored-by: Milos Djermanovic <[email protected]>

softius dismissed nzakas’s stale review via 78d37ab October 31, 2024 06:07

Move suppressed messages to LintResult#suppressedMessages

b33e324

nzakas previously approved these changes Nov 1, 2024

View reviewed changes

mdjermanovic reviewed Nov 3, 2024

View reviewed changes

mdjermanovic previously approved these changes Nov 4, 2024

View reviewed changes

Reports all errors when the allowed number is exceeded

c005f3b

softius dismissed stale reviews from mdjermanovic and nzakas via c005f3b November 4, 2024 19:26

Add example fo the error message

f134daa

fasttime reviewed Nov 5, 2024

View reviewed changes

fasttime reviewed Nov 6, 2024

View reviewed changes


		Furthermore, we are adding one more reason to exit with an error code (see "Maintaining a lean baseline"). This might have some negative side-effects to wrapper scripts that assume that error messages are available when that happens. We could introduce a different exit code, to differentiate between exiting due to unresolved errors or ignored errors that do not occur anymore.

		## Alternatives


		### Suppressing violations of a specific rule

		A new option `--suppress-rule [RULE1]` will be introduced to ESLint CLI. When provided, the existing suppressions file will be updated to include any existing violation of the provided rule. The suppressions file will be created if not already exists. Note that this is option can accept an array of string values.


		The suggested solution always compares against the existing suppressions file, typically `.eslint-suppressions.json`, unless `--suppressions-location` is specified. This makes it easier for existing and new projects to adopt this feature without the need to adjust scripts in `package.json` and CI/CD workflows.

		To perform the comparison, we will go through each result and message from `ESLint.lintFiles`, checking each error `(severity == 2)` against the suppressions file. By design, we ignore warnings since they don't cause eslint to exit with an error code and serve a different purpose. If the file and rule are listed in the suppressions file, we can move the message to `LintResult#suppressedMessages` and ignore the result message.

	if (options.suppressAll) {
	suppressionsManager.suppressAll(results);
	} else if (options.suppressRule) {
	suppressionsManager.suppressByRule(results, options.suppressRule);
	} else if (options.pruneSuppressions) {
	suppressionsManager.prune();
	}

		log.error("There are left suppressions that do not occur anymore. Consider re-running the command with `--prune-suppressions`.");
		return 2;

feat: Introduce a way to suppress violations #119

Are you sure you want to change the base?

feat: Introduce a way to suppress violations #119

Conversation

softius commented Apr 22, 2024 • edited Loading

Summary

Related Issues

linux-foundation-easycla bot commented Apr 22, 2024 • edited Loading

Choose a reason for hiding this comment

fasttime commented Apr 23, 2024

nzakas left a comment

Choose a reason for hiding this comment

nzakas commented May 15, 2024

octogonz commented May 15, 2024 • edited Loading

nzakas commented May 16, 2024

octogonz commented May 21, 2024

fasttime commented May 28, 2024

Humni commented May 29, 2024

nzakas left a comment

Choose a reason for hiding this comment

nzakas commented Jun 3, 2024

kevin-y-ang commented Jun 6, 2024

nzakas commented Jun 7, 2024

kevin-y-ang commented Jun 7, 2024 • edited Loading

Humni commented Jun 10, 2024

nzakas commented Jun 10, 2024

nzakas commented Jun 24, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nzakas commented Aug 28, 2024

Choose a reason for hiding this comment

mdjermanovic Aug 29, 2024 • edited Loading

Choose a reason for hiding this comment

mdjermanovic commented Aug 29, 2024

nzakas commented Aug 29, 2024

fasttime commented Aug 30, 2024 • edited Loading

nzakas commented Sep 11, 2024

fasttime commented Oct 18, 2024

softius commented Oct 31, 2024

softius commented Oct 31, 2024

nzakas left a comment

Choose a reason for hiding this comment

mdjermanovic commented Nov 3, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nzakas commented Nov 4, 2024

mdjermanovic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

softius commented Apr 22, 2024 •

edited

Loading

linux-foundation-easycla bot commented Apr 22, 2024 •

edited

Loading

octogonz commented May 15, 2024 •

edited

Loading

kevin-y-ang commented Jun 7, 2024 •

edited

Loading

mdjermanovic Aug 29, 2024 •

edited

Loading

fasttime commented Aug 30, 2024 •

edited

Loading