scripts: flash: Add west config for flash skip rebuild #96115

decsny · 2025-09-16T22:41:59Z

Add a west config option to skip rebuilds by default or not when doing west flash.

marc-hb · 2025-09-16T23:06:05Z

What is the use case? When would someone want to flash an outdated image? Or is this because the no-op build is too slow? It shouldn't be...

EDIT:
cc:

scripts: west_commands: add build.symlinks and extend build.dir-fmt #96231, @thorsten-klein

scripts/west_commands/run_common.py

decsny · 2025-09-16T23:12:21Z

What is the use case? When would someone want to flash an outdated image? Or is this because the no-op build is too slow? It shouldn't...

The skip rebuild option already exists. I am just adding a west config option for it so that someone doesn't have to type it every time if they generally don't want it to behave that way. So I don't think it's in the scope of the PR to debate the utility of that already-existing option.

I can say though that my use case is that I often am having builds on multiple different SHAs due to I am trying to compare behaviors or something at different points in history, and using different build directory to store the builds so that they don't overwrite each other on the default path. And checking out to a different SHA causes the image to get rebuilt if it's from a different SHA, so this is really annoying because I have to keep doing git checkout just to flash/debug the proper image or else be typing --skip-rebuild all the time. So I just want a config option to make this the default if desired, which I do.

marc-hb

The skip rebuild option already exists.

I just noticed now... I had not yet because you're adding/duplicating the config logic in a different place than the command-line flag logic. Please keep all that logic in the same place. You're also adding documentation for the config far away from --skip-rebuild help, is that necessary and why?

So I don't think it's in the scope of the PR to debate the utility of that already-existing option.

While less so, it can still be valid to revisit the value of a feature when changing it. Not every feature was a good idea and extending bad ones is not either.

Also, things evolve and what was good ages ago may not still be today. This particular feature was added 7 years ago in a giant commit and totally different environment and I couldn't find any rationale for it:
https://github.com/zephyrproject-rtos/west/commits/b1477f67d69d

EDIT: this was only the 6th west commit of all time!

West was in its very first year back then and in a "frantic" development phase. @mbolivar , any memories of --skip-rebuild?

I can say though that my use case using different build directory to store the builds so that they don't overwrite each other on the default path.

Thanks for sharing! I'm still not sure what is the best way to deal with it but it does sound like a common enough use case.

decsny · 2025-09-16T23:45:23Z

I just noticed now... I had not yet because you're adding/duplicating the config logic in a different place than the command-line flag logic. Please keep all that logic in the same place.

I'm not sure where to put it then, I just did a similar thing to how config.get is used elsewhere in this file such as for build.guess-dir

You're also adding documentation for the config far away from --skip-rebuild help, is that necessary and why?

I am following the same style as the west build documentation section right above it to be consistent about where/how we document the custom west commands' config options, you can view on https://docs.zephyrproject.org/latest/develop/west/build-flash-debug.html#configuration-options

Also, the reason I even found this doc page to put it on at all, is because this page: https://docs.zephyrproject.org/latest/develop/west/config.html#built-in-configuration-options says that the doc of the west config options for the custom commands is on their specific page, so I looked up west flash on the doc site search, and this page seemed like the best result, since it had documented the west build configs also

marc-hb · 2025-09-16T23:50:46Z

While less so, it can still be valid to revisit the value of a feature when changing it. Not every feature was a good idea and extending bad ones is not either.

A big difference between --skip-rebuild and this new flash.skip-rebuild config is that the first one is:

much harder to forget and miss in interactive use
visible and persisted in build logs

Forgetting that flash.skip-rebuild is ON can waste a LOT of time. This risk must be balanced against saving a bit of typing; I'm not sure it's worth it. Surely, when testing different --build-dir you recall the previous command and do not re-enter --skip-rebuild every time, right?

Finally, why not just this instead?

--- a/scripts/west_commands/run_common.py
+++ b/scripts/west_commands/run_common.py
@@ -142,7 +142,7 @@ def add_parser_common(command, parser_adder=None, parser=None):
                        help=argparse.SUPPRESS)
     group.add_argument('-r', '--runner',
                        help='override default runner from --build-dir')
-    group.add_argument('--skip-rebuild', action='store_true',
+    group.add_argument('-s', '--skip-rebuild', action='store_true',
                        help='do not refresh cmake dependencies first')
     group.add_argument('--domain', action='append',
                        help='execute runner only for given domain')

It's not like this particular flash sub-command is anywhere close to running out of the 26 letters of the ASCII alphabet.

marc-hb · 2025-09-16T23:56:45Z

Please keep all that logic in the same place.

I'm not sure where to put it then

?

    if not user_args.skip_rebuild:
        rebuild(command, build_dir, user_args)

    # Re-build unless asked not to, to make sure the output is up to date.
    if build_dir and not args.skip_rebuild:
        rebuild(command, build_dir, args)

such as for build.guess-dir

I don't think build.guess-dir matters much here.

I am following the same style as the west build documentation section right

Fair enough... I don't have a strong opinion there but if not in the same place for some reason, then the documentations of --skip-rebuild and flash.skip-rebuild should definitely not look like they don't even know each other.

pdgendt · 2025-09-17T06:37:39Z

scripts/west_commands/run_common.py

        log.die(f'no CMake cache found (expected one at {cache_file})')

 def rebuild(command, build_dir, args):
+    skip_rebuild_config = config.get('flash', 'skip-rebuild', fallback='false')


I'm not against this proposal, but currently the flash.skip-rebuild option would also be used for debug/simulate/robot, which feels wrong.

It can be "fixed" with

Suggested change

skip_rebuild_config = config.get('flash', 'skip-rebuild', fallback='false')

skip_rebuild_config = config.get(command.name, 'skip-rebuild', fallback='false')

But this also can become somewhat of a footgun.

An alternative (already existing) solution is to create an alias (can be set globally too):

$ west config alias.flash -- "flash --skip-rebuild"

yes, I agree this should have better granularity.

That said, I think having the config option can make sense.
Personally I often use the west debugserver --skip-rebuild because I don't want the debugserver to start messing with my build folder.

So principle is accepted.

tejlmand · 2025-09-17T07:58:29Z

Forgetting that flash.skip-rebuild is ON can waste a LOT of time.

but doesn't that go for any west config command ?
If I've changed my west config manifest.path foo and forgot about it, then that also can take time to remember.

Or if setting some fixed CMake args using: west config build.cmake-args.

A west config option will not be present in the config files unless the user as explicitly set it, which makes it the users responsibility. It's simple, don't use it if you don't like it.

As for the --skip-rebuild option, then I do see the use-case presented although I wouldn't use it on west flash, but I certainly use it most of the times with west debugserver.

So granularity should be improved, so that if being able to use skip-rebuild for flash, then it should only apply to west flash, not west debug / debugserver / etc, those should support their own: west config debug.skip-rebuild / debugserver.skip-rebuild / etc as mentioned: #96115 (comment)

pdgendt · 2025-09-17T08:38:46Z

scripts/west_commands/run_common.py

        log.die(f'no CMake cache found (expected one at {cache_file})')

 def rebuild(command, build_dir, args):
+    skip_rebuild_config = config.get('flash', 'skip-rebuild', fallback='false')


Also suggest to use getboolean

Suggested change

skip_rebuild_config = config.get('flash', 'skip-rebuild', fallback='false')

skip_rebuild_config = config.getboolean(command.name, 'skip-rebuild', fallback='false')

marc-hb · 2025-09-17T18:16:58Z

$ west config alias.flash -- "flash --skip-rebuild"

Nice! @decsny can you please try this? Or something like this if you prefer not shadowing:

west config alias.flashSB -- "flash --skip-rebuild"

but doesn't that go for any west config command ?

It depends: they don't all have the same cost when forgetting them; they are not all "footguns". Forgetting that you configured grep.color is never going to cost you a lot of time.

If I've changed my west config manifest.path foo and forgot about it, then that also can take time to remember.

Right, this one looks like a pretty big footgun. But unlike this PR, there is no command-line or other alternative for config manifest.path, is there? I mean it's the only way to achieve this without a git diff?

Or if setting some fixed CMake args using: west config build.cmake-args.

Agreed, this is another footgun but the effect of this one is probably easier to spot in the build logs?

Anyway, we can debate and compare footguns until the cows come home but already having an arsenal is not a good enough reason to add yet another, new footgun.

A west config option will not be present in the config files unless the user as explicitly set it, which makes it the users responsibility. It's simple, don't use it if you don't like it.

Footguns are never "simple", they is always a benefit/risk trade-off. For this particular one, the benefit seems extremely low. In every Zephyr survey I keep seeing this coming back: "make Zephyr more newbie-friendly".

Also, @pdgendt already added the "ultimate swiss army footgun" a.k.a. config.alias. So, do we really need to keep adding new ones?

PS: my "request for changes" is about the current implementation.

thorsten-klein · 2025-09-18T18:59:47Z

This could be related to my use case that users want to keep multiple different builds and switch between them:
Ref: #96231

In case of OP's use case it could make sense to extend build.dir-fmt to support {branch}, {commit} or {timestamp} to ensure a unique build folder per branch or commit or always (timestamp)

tejlmand · 2025-09-18T19:39:20Z

Or if setting some fixed CMake args using: west config build.cmake-args.

Agreed, this is another footgun but the effect of this one is probably easier to spot in the build logs?

I guess that depends on the user.
You can't imagine the things that people don't notice in the CMake output, even though we try to only print the most important 😞

Regarding the rebuild / no rebuild, then I would say it's just as simple to spot:

$ west flash
-- west flash: rebuilding    <--- it tries to rebuild
ninja: no work to do.
-- west flash: using runner nrfutil
...

vs:

$ west flash --skip-rebuild
-- west flash: using runner nrfutil   <---- Goes straight to flash
....

Though if approving the config setting, flash.skip-rebuild, then it probably should be highlighted, for example like this:

$ west flash --skip-rebuild
-- west flash: skip rebuild   <-- user is informed
-- west flash: using runner nrfutil
....

But there is one thing we should have if supporting west config flash.skip-rebuild true, and that is to overrule that setting on command line.

For example I can enable sysbuild by default, but deselect it on a specific build, like this:

$ west config build.sysbuild true                # Use sysbuild in general
$ west build -b plank --no-sysbuild <sample>     # Do not use sysbuild in this case

So if we're going to support west config flash.skip-rebuild true then it must be possible to overwrite this on command line, for example by using:

$ west flash --force-rebuild

Side-note: if introducing --force-rebuild, then it probably better to name the flags --build / --no-build or --rebuild / --no-rebuild.

For this particular one, the benefit seems extremely low.

Like anything else, I would say it depends.
One thing that have hit me is when trying to run samples in debugger where you might have a reference sample in build_working.
The if you do west flash -d build_working and forget --skip-rebuild, then the build from the working SHA is immediately cleared, and you need to checkout that SHA and rebuild, just to jump back to where you were.
But again, that's just an annoyance, nothing where you spend time tracing down why it's not rebuilding.

tejlmand

though I do like the west config flash.skip-rebuild true, then for such a setting it must be possible to overwrite the config setting directly on command line when invoking west flash.

For example like this (I want my rebuild):

$ west flash --force-rebuild

Note, instead of implementing --force-rebuild, then it's probably better to rename option so we have --rebuild / --no-rebuild or similar.
See also west config flash.skip-rebuild true

marc-hb · 2025-09-18T20:10:21Z

You also need to make sure the command-line takes precedence over the config.

So if we're going to support west config flash.skip-rebuild true then it must be possible to overwrite this on command line when invoking west flash. For example like this (I want my rebuild):
$ west flash --force-rebuild

I think west flash --skip-rebuild=false would be preferable. One fewer flag and "Command line has precedence over config" is more obvious than "force has precedence over skip".

pdgendt · 2025-09-19T06:58:18Z

I think west flash --skip-rebuild=false would be preferable. One fewer flag and "Command line has precedence over config" is more obvious than "force has precedence over skip".

I disagree, we should use --no-rebuild and --rebuild similar to many other tools/compilers using this pattern. We already have --no-sysbuild/--sysbuild too.

We even have an extendable argparse.Action class we can re-use:

zephyr/scripts/west_commands/runners/core.py

Lines 380 to 383 in 27fa721

    
           class _ToggleAction(argparse.Action): 
        
               def __call__(self, parser, args, ignored, option): 
        
                   setattr(args, self.dest, not option.startswith('--no-'))

tejlmand · 2025-09-19T07:13:59Z

I think west flash --skip-rebuild=false would be preferable.

I always need to re-read and double-check such double negations first.
If a true|false pattern is to be used, then it should be straight forward like: --rebuild=true or --rebuild=false.

but then I prefer the --rebuild / --no-rebuild as that's a pattern already used, and I favor consistency.

marc-hb · 2025-09-19T16:02:41Z

I don't like double negations either and I like consistency too, unfortunately --skip-rebuild has existed since west 6th commit of all time (when thinking about User Interface details was not the priority...) Maybe there could be new --[no-]rebuild (and config.rebuild=false) and keep --skip-rebuild as an alias for backwards-compatibility?

I don't have a strong opinion for those names, my previous comment was all about not renaming the "true" and "false" booleans to "skip" and "force". That's even more confusing that double negations because it looks like that "skip" and "force" could refer to a different type of "build". Double-negations are confusing and time-consuming but they are at least not ambiguous.

tejlmand · 2025-09-19T18:56:08Z

That's even more confusing that double negations because it looks like that "skip" and "force" could refer to a different type of "build".

Sorry, I never intended to propose force as name in argument. Only to highlight the intention / reason for having the ability to overrule whatever setting existed in config file.
As I wrote:
Side-note: if introducing --force-rebuild, then it probably better to name the flags --build / --no-build or --rebuild / --no-rebuild.

and keep --skip-rebuild as an alias for backwards-compatibility?

I think that's a fine thing, and if we want to cleanup later then we can start deprecating --skip-rebuild.

decsny · 2025-09-23T15:02:53Z

If I understand the convergence of the discussion was to introduce --rebuild and --no-rebuild, and to make the west config xxx.rebuild generic to any command ?

mbolivar · 2025-09-30T19:36:07Z

Consensus makes sense to me. For the record,

. @mbolivar , any memories of --skip-rebuild?

@marc-hb consider the use case "As a developer, I have to flash multiple instances of the same board with the same binary, and I want to ensure that there are no differences in the different binaries flashed. I have an old build directory I would like to use for this purpose. My working tree has diverged significantly from when I built it."

mbolivar · 2025-09-30T19:36:51Z

@marc-hb although to be honest, the truth is that @SebastianBoe wanted us to rebuild by default, and he was the build system maintainer back then so I thought it best not to argue even though I disagreed. My personal preference would have been for the --skip-rebuild behavior to be the default.

decsny · 2025-10-01T20:07:59Z

Please keep all that logic in the same place.

It's not just a code style issue BTW. You also need to make sure the command-line takes precedence over the config.

I'm actually not sure what you're referring here though because one of the things I did on the original commit here is refactor to try to put all the logic in the same place, since there was some duplication across the file, maybe you can be more specific of what you mean?

outdated review

Add a west config option to skip rebuilds by default or not when doing west flash. Signed-off-by: Declan Snyder <[email protected]>

mbolivar · 2025-10-01T22:29:10Z

It's not just a code style issue BTW. You also need to make sure the command-line takes precedence over the config.

I'm actually not sure what you're referring here though because one of the things I did on the original commit here is refactor to try to put all the logic in the same place, since there was some duplication across the file, maybe you can be more specific of what you mean?

@decsny I think the idea is to make sure that west flash --foo always takes precedence over any west config flash.foo setting.

marc-hb · 2025-10-01T23:01:18Z

@decsny I think the idea is to make sure that west flash --foo always takes precedence over any west config flash.foo setting.

Yes - and good luck reviewing and maintaining the correct precedence if the code for one were far away from the other.

because one of the things I did on the original commit here is refactor to try to put all the logic in the same place

I noticed that one of your very first versions https://github.com/zephyrproject-rtos/zephyr/blob/cef1c2527e0686f6dcf60174aa192c7fbae98d32/scripts/west_commands/run_common.py still had some "skip" code in two places (lines 250 and 730). You force-pushed and regrouped everything that while I was making that comment #96115 (review). I didn't check again and did not notice the change, apologies!

decsny · 2025-10-01T23:21:40Z

@decsny I think the idea is to make sure that west flash --foo always takes precedence over any west config flash.foo setting.

Yes - and good luck reviewing and maintaining the correct precedence if the code for one were far away from the other.

because one of the things I did on the original commit here is refactor to try to put all the logic in the same place

I noticed that one of your very first versions https://github.com/zephyrproject-rtos/zephyr/blob/cef1c2527e0686f6dcf60174aa192c7fbae98d32/scripts/west_commands/run_common.py still had some "skip" code in two places (lines 250 and 730). You force-pushed and regrouped everything that while I was making that comment #96115 (review). I didn't check again and did not notice the change, apologies!

ok, I dont remember if that was the case, I didnt even remember i pushed multiple times

anyways, I updated the PR for the multiple command and symmetrical cli as requested, please check if the logic is how you imagined

tejlmand · 2025-10-02T10:21:58Z

scripts/west_commands/run_common.py

+    group.add_argument('-s', '--skip-rebuild', "--no-rebuild", action='store_true',
                       help='do not refresh cmake dependencies first')
+    group.add_argument('--force-rebuild', '--rebuild', action='store_true',
+                       help='force a refresh of the cmake dependencies before running')


I think those should be in a mutual exclusive group.

tejlmand · 2025-10-02T10:23:46Z

scripts/west_commands/run_common.py

-    group.add_argument('--skip-rebuild', action='store_true',
+    group.add_argument('-s', '--skip-rebuild', "--no-rebuild", action='store_true',
                       help='do not refresh cmake dependencies first')
+    group.add_argument('--force-rebuild', '--rebuild', action='store_true',


remove the --force-rebuild.

We should just have --rebuild / --no-rebuild as the primary flags. And we're only keeping --skip-rebuild for backwards compatibility reasons.

Suggested change

group.add_argument('--force-rebuild', '--rebuild', action='store_true',

group.add_argument('--rebuild', action='store_true',

I think we need default=None here, so that we can determine later if the user has specified the argument (True/False) or if it was not specified (None).

I think we need default=None here,...

I think so too, otherwise how would we know when to consider/ignore the west config? See below.

thorsten-klein · 2025-10-02T20:21:49Z

scripts/west_commands/run_common.py

+    # Therefore, only two cases in which we skip:
+
+    # user manually specified skip rebuild, so we skip
+    if args.skip_rebuild:


Just a small hint:
I’d suggest moving this line to the very top of the function. We can return directly (without considering the config at all) if the user explicitly requested --no-rebuild.

thorsten-klein · 2025-10-02T20:25:32Z

scripts/west_commands/run_common.py

 def rebuild(command, build_dir, args):
+    rebuild_config = config.get(command.name, 'rebuild', fallback='true').lower()


In the documentation it says Boolean, so I would expect getboolean here?

thorsten-klein · 2025-10-02T20:29:12Z

scripts/west_commands/run_common.py

+    rebuild_config = config.get(command.name, 'rebuild', fallback='true').lower()
+
+    # Truth table ->
+    # config rebuild | manual option | rebuild?


For me the table is not so intuitive to understand.
Maybe it would be better to use the real variable names and list all combinations rebuild_config (True / False), args.skip_rebuild (True / False) and args.rebuild with (True / False / None).

# rebuild_config | args.skip_rebuild | args.rebuild | rebuild? # ...

If the table is too long it can also be moved to the test (or the parameterized test cases represent this table), so this long comment does not need to be placed within the productive code.

I don't think a truth table is not needed for this, it gives too much to think about.

AFAIK things should work like this:

"--skip-rebuild" is deprecated. Could print a warning.

using "--skip-rebuild" and any new option at the same time aborts with an error message. Eliminates "old vs new" precedence questions.

"--skip-rebuild" must always have the exact same behavior as "--no-rebuild" (warning aside)

As usual, the CLI has precedence. The west config is ignored when anything is passed on the command line (which is why the CLI default should probably be None).

1 and 2 have a error/warning message which is better than comments
4 is obvious.
3 should be explained in the --help.

~~So, no comment needed?~~
So, no truth table comment needed?

Comments are of course needed here.
But the full truth table (2x2x3=12 lines long) would be fine for me to live in the test (which is still missing). Just personal favor.

thorsten-klein · 2025-10-02T20:35:10Z

scripts/west_commands/run_common.py

    except FileNotFoundError:
        log.die(f'no CMake cache found (expected one at {cache_file})')

 def rebuild(command, build_dir, args):


Maybe some parameterized test for this function would make sense to test all combinations of args.rebuild (True,False,None), args.skip_rebuild (True / False) and config_rebuild (True / False / None) versus the truth table.

thorsten-klein · 2025-10-02T20:42:39Z

scripts/west_commands/run_common.py

-    group.add_argument('--skip-rebuild', action='store_true',
+    group.add_argument('-s', '--skip-rebuild', "--no-rebuild", action='store_true',
                       help='do not refresh cmake dependencies first')
+    group.add_argument('--force-rebuild', '--rebuild', action='store_true',


I think we need default=None here, so that we can determine later if the user has specified the argument (True/False) or if it was not specified (None).

thorsten-klein · 2025-10-02T20:46:48Z

scripts/west_commands/run_common.py

+        return
+
+    # config says to skip, and user did not manually override, so skip
+    if rebuild_config == 'false' and not args.force_rebuild:


Should be bool.

marc-hb · 2025-10-03T11:04:36Z

scripts/west_commands/run_common.py

    group.add_argument('-r', '--runner',
                       help='override default runner from --build-dir')
-    group.add_argument('--skip-rebuild', action='store_true',
+    group.add_argument('-s', '--skip-rebuild', "--no-rebuild", action='store_true',


Use argparse.BooleanOptionalAction and you get the negative --no-... option for free, no need to declare both.

zephyrbot added area: Documentation area: West West utility labels Sep 16, 2025

zephyrbot requested review from carlescufi, kartben, marc-hb, mbolivar, nashif, pdgendt and swinslow September 16, 2025 22:43

zephyrbot assigned pdgendt Sep 16, 2025

decsny force-pushed the feature/west_flash_skip_rebuild_config branch from cef1c25 to 865161f Compare September 16, 2025 23:06

marc-hb reviewed Sep 16, 2025

View reviewed changes

scripts/west_commands/run_common.py Outdated Show resolved Hide resolved

decsny force-pushed the feature/west_flash_skip_rebuild_config branch from 865161f to cb373e6 Compare September 16, 2025 23:07

decsny force-pushed the feature/west_flash_skip_rebuild_config branch from cb373e6 to 3ec8406 Compare September 16, 2025 23:13

marc-hb previously requested changes Sep 16, 2025

View reviewed changes

pdgendt reviewed Sep 17, 2025

View reviewed changes

This comment was marked as resolved.

Sign in to view

tejlmand requested changes Sep 18, 2025

View reviewed changes

decsny force-pushed the feature/west_flash_skip_rebuild_config branch from 3ec8406 to 35945f6 Compare October 1, 2025 20:30

decsny requested review from tejlmand, pdgendt and marc-hb October 1, 2025 21:38

scripts: flash: Add west config for flash skip rebuild

98408b4

Add a west config option to skip rebuilds by default or not when doing west flash. Signed-off-by: Declan Snyder <[email protected]>

decsny force-pushed the feature/west_flash_skip_rebuild_config branch from 35945f6 to 98408b4 Compare October 1, 2025 21:47

This comment was marked as spam.

Sign in to view

tejlmand requested changes Oct 2, 2025

View reviewed changes

thorsten-klein reviewed Oct 2, 2025

View reviewed changes

marc-hb reviewed Oct 3, 2025

View reviewed changes

EmilioCBen approved these changes Oct 7, 2025

View reviewed changes

	skip_rebuild_config = config.get('flash', 'skip-rebuild', fallback='false')
	skip_rebuild_config = config.get(command.name, 'skip-rebuild', fallback='false')

	skip_rebuild_config = config.get('flash', 'skip-rebuild', fallback='false')
	skip_rebuild_config = config.getboolean(command.name, 'skip-rebuild', fallback='false')

	group.add_argument('--force-rebuild', '--rebuild', action='store_true',
	group.add_argument('--rebuild', action='store_true',

		def rebuild(command, build_dir, args):
		rebuild_config = config.get(command.name, 'rebuild', fallback='true').lower()

scripts: flash: Add west config for flash skip rebuild #96115

Are you sure you want to change the base?

scripts: flash: Add west config for flash skip rebuild #96115

Conversation

decsny commented Sep 16, 2025

Uh oh!

marc-hb commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

decsny commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marc-hb left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

decsny commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marc-hb commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marc-hb commented Sep 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pdgendt Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tejlmand commented Sep 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marc-hb commented Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

thorsten-klein commented Sep 18, 2025

Uh oh!

tejlmand commented Sep 18, 2025

Uh oh!

tejlmand left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marc-hb commented Sep 18, 2025

Uh oh!

pdgendt commented Sep 19, 2025

Uh oh!

tejlmand commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marc-hb commented Sep 19, 2025

Uh oh!

tejlmand commented Sep 19, 2025

Uh oh!

decsny commented Sep 23, 2025

Uh oh!

mbolivar commented Sep 30, 2025

Uh oh!

mbolivar commented Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

decsny commented Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as spam.

mbolivar commented Oct 1, 2025

Uh oh!

marc-hb commented Oct 1, 2025

Uh oh!

decsny commented Oct 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tejlmand Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

marc-hb commented Sep 16, 2025 •

edited

Loading

decsny commented Sep 16, 2025 •

edited

Loading

marc-hb left a comment •

edited

Loading

decsny commented Sep 16, 2025 •

edited

Loading

marc-hb commented Sep 16, 2025 •

edited

Loading

marc-hb commented Sep 16, 2025 •

edited

Loading

pdgendt Sep 17, 2025 •

edited

Loading

marc-hb commented Sep 17, 2025 •

edited

Loading

tejlmand left a comment •

edited

Loading

tejlmand commented Sep 19, 2025 •

edited

Loading

mbolivar commented Sep 30, 2025 •

edited

Loading

decsny commented Oct 1, 2025 •

edited

Loading

tejlmand Oct 2, 2025 •

edited

Loading

thorsten-klein Oct 2, 2025 •

edited

Loading

marc-hb Oct 3, 2025 •

edited

Loading

thorsten-klein Oct 2, 2025 •

edited

Loading