sys/ztimer: model ztimer_periph_lptimer for Kconfig #18783

jue89 · 2022-10-21T15:29:48Z

Contribution description

While working on #18760, I realized that #17654 hasn't modeled the module ztimer_periph_lptimer.

This PR tries to fix that. For that I added the feature HAS_ZTIMER_PERIPH_LPTIMER_CONFIG which should be selected by boards that has the required configuration for ztimer_periph_lptimer.

Testing procedure

diff --git a/tests/ztimer_msg/Makefile b/tests/ztimer_msg/Makefile
index 247bbc2030..0d53a02304 100644
--- a/tests/ztimer_msg/Makefile
+++ b/tests/ztimer_msg/Makefile
@@ -1,6 +1,6 @@
 include ../Makefile.tests_common
 
-USEMODULE += ztimer_usec
+USEMODULE += ztimer_msec
 
 # uncomment this to test using ztimer msec
 #USEMODULE += ztimer_msec
diff --git a/tests/ztimer_msg/app.config.test b/tests/ztimer_msg/app.config.test
index 2fc4266478..1857316235 100644
--- a/tests/ztimer_msg/app.config.test
+++ b/tests/ztimer_msg/app.config.test
@@ -1,4 +1,4 @@
 # this file enables modules defined in Kconfig. Do not use this file for
 # application configuration. This is only needed during migration.
 CONFIG_MODULE_ZTIMER=y
-CONFIG_ZTIMER_USEC=y
+CONFIG_MODULE_ZTIMER_MSEC=y

With Kconfig support

TEST_KCONFIG=1 make -C tests/ztimer_msg  BOARD=xg23-pk6068a LOG_LEVEL=LOG_DEBUG flash term
2022-10-26 22:28:56,539 # ztimer_init(): ZTIMER_LPTIMER using periph timer 1, freq 32768, width 24
2022-10-26 22:28:56,549 # ztimer_init(): ZTIMER_LPTIMER setting block_pm_mode to 255
2022-10-26 22:28:56,549 # ztimer_init(): ZTIMER_MSEC convert_frac from 32768 to 1000
2022-10-26 22:28:56,557 # Help: Press s to start test, r to print it is ready
s
2022-10-26 22:28:59,319 # START
2022-10-26 22:28:59,324 # main(): This is RIOT! (Version: 2023.01-devel-155-g3662e-fix/ztimer_lptimer_kconfig)
2022-10-26 22:28:59,324 # This is thread 2
2022-10-26 22:28:59,324 # sending 1st msg
2022-10-26 22:28:59,329 # now=514:656 -> every 2.0s: Hello World
2022-10-26 22:28:59,329 # sending 2nd msg
2022-10-26 22:28:59,332 # now=514:661 -> every 5.0s: This is a Test
2022-10-26 22:28:59,337 # This is thread 3
2022-10-26 22:29:00,337 # sec=515 min=8 hour=0
2022-10-26 22:29:01,332 # now=516:660 -> every 2.0s: Hello World
(...)

Without Kconfig support

TEST_KCONFIG=0 make -C tests/ztimer_msg  BOARD=xg23-pk6068a LOG_LEVEL=LOG_DEBUG flash term
2022-10-26 22:22:00,617 # ztimer_init(): ZTIMER_LPTIMER using periph timer 1, freq 32768, width 24
2022-10-26 22:22:00,622 # ztimer_init(): ZTIMER_LPTIMER setting block_pm_mode to 255
2022-10-26 22:22:00,627 # ztimer_init(): ZTIMER_MSEC convert_frac from 32768 to 1000
2022-10-26 22:22:00,630 # Help: Press s to start test, r to print it is ready
s
2022-10-26 22:22:03,712 # START
2022-10-26 22:22:03,717 # main(): This is RIOT! (Version: 2023.01-devel-155-g3662e-fix/ztimer_lptimer_kconfig)
2022-10-26 22:22:03,717 # This is thread 2
2022-10-26 22:22:03,721 # sending 1st msg
2022-10-26 22:22:03,722 # now=514:983 -> every 2.0s: Hello World
2022-10-26 22:22:03,727 # sending 2nd msg
2022-10-26 22:22:03,727 # now=514:988 -> every 5.0s: This is a Test
2022-10-26 22:22:03,730 # This is thread 3
2022-10-26 22:22:04,735 # sec=515 min=8 hour=0
2022-10-26 22:22:05,730 # now=516:987 -> every 2.0s: Hello World
(...)

Issues/PRs references

riot-ci · 2022-10-21T15:37:51Z

Murdock results

✔️ PASSED

ef3e192 boards/xg23-pk6068a: provide ZTIMER_LPTIMER configuration

Success	Failures	Total	Runtime
2000	0	2000	06m:33s

Artifacts

Documentation preview

This only reflects a subset of all builds from https://ci-prod.riot-os.org. Please refer to https://ci.riot-os.org for a complete build for now.

MrKevinWeiss · 2022-10-24T05:43:53Z

I have always struggled with the ztimer modelling. Maybe it would be nice test with setting NIGHTLY=${NIGHTLY:-1} in the .murdock file and add a REMOVEME commit. See if matches the nightly results (as there are still errors).

jue89 · 2022-10-24T09:00:11Z

Yes, this definitely needs an overhaul. One half of the dependency resolution is put in the init.c the other half in the Makefile. And Kconfig is there as well ... maybe Kconfig can also reduce complexity that can be observed in the inti.c.

kfessel · 2022-10-25T08:46:13Z

Yes, this definitely needs an overhaul. One half of the dependency resolution is put in the init.c the other half in the Makefile. And Kconfig is there as well ... maybe Kconfig can also reduce complexity that can be observed in the inti.c.

This is very correct Ztimer had this situation before i rearranged (semi-rewrote) init.c but it was less readable (and there for less visible that there was dependency resolution inside).
I think Kconfig would be able to handle all the complexity of Ztimer moving the configuration from init.c. But with make we would either have very complex Makefiles or more seemingly valid configurations that fail building. I also seems that we are not realy going to abandon the configuration part of make soon.

Thank you for modeling the lptimer thing in Kconfig.

kfessel

This seem valid from my POV. ✔️

I am not sure if i would default to lptimer or better have rtt as a default. rtt might more often than lptimer have its own power domain in the mcu i think. but on the other hand there are no mcu or boards in riot that have a default lptimer.

Seems goods i think there should be a review from one of our Kconfig experts. (i was not sure about the HAS_ modeling but that seems to be quiet common.

MrKevinWeiss · 2022-10-25T11:25:05Z

Hmmm, I don't see any related failures in the nightlies.

MrKevinWeiss · 2022-10-25T11:31:46Z

Regarding the HAS_* in kconfig:

This is used to match FEATURES_PROVIDED in the makefile. So if you have FEATURES_PROVIDED+=ztimer_periph_lptimer that would be like selecting the symbol HAS_ZTIMER_PERIPH_LPTIMER. Now, if there is nothing that exists in the makefile for a specific symbol, maybe just a nice way to organize things, then we use HAVE_* to indicate the same intent with but without the makefile containing that information. This is done a lot with the drivers, we can say some boards HAVE_A_DRIVER then the module can determine if it is appropriate to bring it in.

sys/ztimer/Kconfig

jue89 · 2022-10-25T11:41:45Z

Hmm, after reading @MrKevinWeiss comment, I'd like to model this in Makefiles as well. But I don't know how to achieve that. I'm looking for some logic like this:

If ztimer_msec or ztimer_sec are in USEMODULE and ztimer_lptimer_config is in FEATURES_PROVIDED, I wan't to add this features to FEATURES_REQUIRED. This results into ztimer_periph_lptimer being added to USEMODULE. We can't do something like this with the Makefiles, don't we?

(Off topic: What's blocking the shift to Kconfig-only dependency resolution?)

MrKevinWeiss · 2022-10-25T11:51:18Z

What's blocking the shift to Kconfig-only dependency resolution?

Manpower mostly... All the hard things are left.

I would drop the ztimer_lptimer_config and just name it ztimer_periph_lptimer, as that is the module name you need.
If you do that than you probably should provide it in the periph conf of the boards you want to support.

Thus:

board_x adds the configuration defined in the test to the periph_conf.h
in board_x makefile.features add FEATURES_PROVIDED+=ztimer_periph_lptimer
Have a test (or test configuration) that specifies FEATURES_REQUIRED+=ztimer_periph_lptimer or somewhere in the ztimer backend selection in the makefile.dep try to select it if it is provided.

Just keep in mind that there are some unsolvable conditions that the makefile resolves that Kconfig cannot (because Kconfig cannot have race conditions).

My advice, try to not make the system super smart, put a little burden on the user to select what they want in order to simplify the system UNTIL we are done with the migration. Then there is only one area you need to manage and a clearer set of rules to follow when trying to add the "we know what you want" intelligence of the build system.

kfessel · 2022-10-25T13:07:37Z

If ztimer_msec or ztimer_sec are in USEMODULE and ztimer_lptimer_config is in FEATURES_PROVIDED, I wan't to add this features to FEATURES_REQUIRED. This results into ztimer_periph_lptimer being added to USEMODULE. We can't do something like this with the Makefiles, don't we?

I don't think we should default to lptimer yet - since most boards don't have a lptimer configured. (there for some board would have the rtt avail by default and some not increasing the inconsistency)

(Off topic: What's blocking the shift to Kconfig-only dependency resolution?)

I asked a similar question some time ago and got the answer: Make configuration shall always be possible (-I conclude-> everything we model in Kconfig has to be in Make as well (We do not shift); but maybe this is a misinterpretation of the answer i got by me )

MrKevinWeiss · 2022-10-25T16:50:11Z

I asked a similar question some time ago and got the answer: Make configuration shall always be possible (-I conclude-> everything we model in Kconfig has to be in Make as well (We do not shift); but maybe this is a misinterpretation of the answer i got by me )

Oh, I was unaware. I think nobody wants to do that twice...

jue89 · 2022-10-26T19:08:02Z

As you have domain specific knowledge with the ztimer stuff, I would think fully and properly modelling that would be great.

I'll try during the next days! At least we could have the backend selection done by Kconfig which is picked up by ztimer_init().

--

#18780 ist merged! I added the ztimer_periph_lptimer-related configuration and made the it the default base for ZTIMER_MSEC and ZTIMER_SEC. I'm curios what's your and Murdock's option on this ;-)

MrKevinWeiss · 2022-10-27T08:52:28Z

I'm curios what's your and Murdock's option on this

Do you mean what Kconfig selects and what make selects?

If so, you can use #18803 to locally check if they match. My solution for trying to mitigate nightly breaking of kconfig.

jue89 · 2022-10-27T09:11:13Z

I'm curios what's your and Murdock's option on this

Do you mean what Kconfig selects and what make selects?

If so, you can use #18803 to locally check if they match. My solution for trying to mitigate nightly breaking of kconfig.

Oh, autocorrect changed "opinion" to "option". My bad - should've noticed :-D But all looks good, I guess ;-)

Maybe @kfessel can have a look onto the dependency resolution and defaults I added since the last time he looked at this PR.

jue89 · 2022-10-27T10:25:47Z

"Lazy users"

sensible defaults are not good enough for some people

Kconfig default logic can only automate so much

select-based magic does not scale -> circular dependencies

Im curios ... what's the better way to describe dependencies? depends on? But this doesn't pull in required dependencies, right?

MrKevinWeiss · 2022-10-27T10:37:19Z

Im curios ... what's the better way to describe dependencies? depends on? But this doesn't pull in required dependencies, right?

This is the debate @leandrolanzieri and I have often, the "Lazy Developer" problem.

Lazy Developers do not want to determine the dependencies themselves each time as this is a lot more effort.
For example, in the linux kernel, one would manually go through and select things until they are happy, meaning they know all the things that go into the system. This is also the encouraged Zephyr way, and makes the modelling much easier.

The way we do it with make (and I agree with) is using select instead of depends on. This makes it easy for the developer as they just need to choose the highest level module and everything underneath gets selected. In my mind, that is what we should go for as it lets applications that only use a high level module not be as sensitive to changes below. The downside is that the modelling is much more difficult as we now have to determine what the user should have. This is especially useful if we provide enough information about the board, making a module selection HAL...

jue89 · 2022-10-27T11:18:54Z

The way we do it with make (and I agree with) is using select instead of depends on. This makes it easy for the developer as they just need to choose the highest level module and everything underneath gets selected. In my mind, that is what we should go for as it lets applications that only use a high level module not be as sensitive to changes below. The downside is that the modelling is much more difficult as we now have to determine what the user should have. This is especially useful if we provide enough information about the board, making a module selection HAL...

The complicated part is to inherit all required features of the selected module and modules that might get selected by this module, right? Sorry for getting side-tracked here ...

Wouldn't it be nice to model this by depends on and have some kind of tool that enables all dependencies until the wanted packet is enabled? (Actually I'm used to the Linux way of me doing the dependency resolution ...)

leandrolanzieri · 2022-10-27T11:29:29Z

Wouldn't it be nice to model this by depends on and have some kind of tool that enables all dependencies until the wanted packet is enabled? (Actually I'm used to the Linux way of me doing the dependency resolution ...)

I 100% agree with this. We come back to this discussion regularly with @MrKevinWeiss. IMO Kconfig models the constraints set by the modules and the system (dependencies, possible values, etc.). That's about it. Another tool (e.g., some solver) would take the modelling + user / app constraints (USEMODULE += foo) and render the configuration(s) that satisfy this.

leandrolanzieri · 2022-10-27T11:32:20Z

Just as a pointer, something like this could be already useful https://github.com/oddlama/autokernel

MrKevinWeiss · 2022-10-27T11:37:59Z

Wouldn't it be nice to model this by depends on and have some kind of tool that enables all dependencies until the wanted packet is enabled?

Ya, we haven't used any tools to successfully get us what we want though... Also what would the app.config look like then, or would we expect the tool to be run as part of the build system?

MrKevinWeiss · 2022-10-27T11:38:36Z

But also maybe we should move this to either a separate issue or in the forum somewhere. It is nice to have another voice!

kfessel · 2022-10-27T12:23:45Z

sys/include/ztimer/config.h

+/**
+ * @brief   The minimum pm mode required for ZTIMER_LPTIMER to run
+ */
+#ifndef CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE
+#  if defined(CONFIG_ZTIMER_MSEC_REQUIRED_PM_MODE)
+#    define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE CONFIG_ZTIMER_MSEC_REQUIRED_PM_MODE
+#  elif defined(CONFIG_ZTIMER_SEC_REQUIRED_PM_MODE)
+#    define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE CONFIG_ZTIMER_SEC_REQUIRED_PM_MODE
+#  else
+#    define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE ZTIMER_CLOCK_NO_REQUIRED_PM_MODE
+#  endif
+#endif
+


this block should not be added (the other blocks a just there for backward compatibility) translating from x-SEC require PM_MODE-X is not correct since the PM is need by the timer that is doing the backend -> if one writs a configuration for LPTIMER they may also set CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE if they know.

translating from
CONFIG_ZTIMER_MSEC_REQUIRED_PM_MODE
would never be reasonable since there is no old code that knew about LPTIMER before ->

do not add this block for LPTIMER

Suggested change

/**

* @brief The minimum pm mode required for ZTIMER_LPTIMER to run

*/

#ifndef CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE

# if defined(CONFIG_ZTIMER_MSEC_REQUIRED_PM_MODE)

# define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE CONFIG_ZTIMER_MSEC_REQUIRED_PM_MODE

# elif defined(CONFIG_ZTIMER_SEC_REQUIRED_PM_MODE)

# define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE CONFIG_ZTIMER_SEC_REQUIRED_PM_MODE

# else

# define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE ZTIMER_CLOCK_NO_REQUIRED_PM_MODE

# endif

#endif

maybe I should have wite in line 106 and 115 : this is only for backward compatibility and not supposed to be used by new code

What do you think of this default:

#ifndef CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE # define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE ZTIMER_CLOCK_NO_REQUIRED_PM_MODE #endif

No defaults forces every board.h to pull in ztimer.h and set the mode to ZTIMER_CLOCK_NO_REQUIRED_PM_MODE if no power management is required ...

yes you are right there should be a fallback value

Suggested change

/**

* @brief The minimum pm mode required for ZTIMER_LPTIMER to run

*/

#ifndef CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE

# if defined(CONFIG_ZTIMER_MSEC_REQUIRED_PM_MODE)

# define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE CONFIG_ZTIMER_MSEC_REQUIRED_PM_MODE

# elif defined(CONFIG_ZTIMER_SEC_REQUIRED_PM_MODE)

# define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE CONFIG_ZTIMER_SEC_REQUIRED_PM_MODE

# else

# define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE ZTIMER_CLOCK_NO_REQUIRED_PM_MODE

# endif

#endif

/**

* @brief The minimum pm mode required for ZTIMER_LPTIMER to run

*/

#ifndef CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE

# define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE ZTIMER_CLOCK_NO_REQUIRED_PM_MODE

#endif

Done. Thank you!

ztimer_periph_lptimer is uses the implementation of ztimer_periph_timer

jue89 · 2022-11-01T11:06:56Z

@kfessel @MrKevinWeiss may I ping you? Is this ready to go into master?

MrKevinWeiss

Looks good from my side. If @kfessel is happy and murdock is happy you have my ACK!

kfessel

@jue89 @MrKevinWeiss I got just a small question left. other than that the Kconfig things seem correct (from the POV of one who did not use Kconfig very much)

kfessel · 2022-11-01T11:51:35Z

boards/xg23-pk6068a/include/board.h

+#define CONFIG_ZTIMER_LPTIMER_DEV            TIMER_DEV(1)
+#define CONFIG_ZTIMER_LPTIMER_FREQ           LFXO_FREQ
+#define CONFIG_ZTIMER_LPTIMER_WIDTH          24
+/** @} */


Why isn't "CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE" defined ?
seems to me that the LETIMER based LPTIMER would at least needs em2 to work
(block the lowest PM_mode em3 (i just saw em4 is pm_off))

i think it this would work out to

#define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE 1

or

#define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE EFM32_PM_MODE_EM3

Good catch! You're right - thank you!

Cf. https://www.silabs.com/documents/public/reference-manuals/efr32xg23-rm.pdf page 150: LETIMER0 is clocked by EM23GRPACLK which is active in EM3. But, this domain is clocked by the LFXO which is active in EM2 ... always confusing ...

I squashed right away. I hope that's okay.

I think p.: 295 provides a good overview over which pm needs to be blocked for which driver to work (hardware is able to wakeup the mcu)

MrKevinWeiss

I think the CONFIG_* just means that the values are guarded but the #ifndef CONFIG_*. AFAIK the equivalent * from CONFIG_* does not need to exist in kconfig, but if it is in Kconfig, it will overwrite...

Which makes things like CONFIG_ZTIMER_LPTIMER_DEV a bit strange if we are wrapping it with a TIMER_DEV since Kconfig does not have objects...

This would also cause a conflict if a ZTIMER_LPTIMER_DEV symbol was defined in kconfig somewhere if the xg23-pk6068a board was selected. That stuff seems closer to the params from periph_conf.h...

Not going to block though, I don't have time to look to close.

MrKevinWeiss · 2022-11-01T13:35:20Z

sys/include/ztimer/config.h

+ * @brief   The minimum pm mode required for ZTIMER_LPTIMER to run
+ */
+#ifndef CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE
+#  define CONFIG_ZTIMER_LPTIMER_BLOCK_PM_MODE ZTIMER_CLOCK_NO_REQUIRED_PM_MODE


do we do the spacing with defines?

I just tried to adapt the surrounding indentation.

The naming has been picked by the already merged PR introducing ztimer_periph_lptimer.

jue89 · 2022-11-02T11:41:52Z

Murdock is green. Is everything addressed, @kfessel?

kfessel · 2022-11-02T12:41:00Z

I think so Am 2. November 2022 12:42:03 MEZ schrieb Juergen Fitschen ***@***.***>:

…

Murdock is green. Is everything addressed, @kfessel? -- Reply to this email directly or view it on GitHub: #18783 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

jue89 · 2022-11-02T12:56:47Z

Thank you for your feedback :-)

kfessel · 2022-11-02T15:49:12Z

ok das nächstemal werf ich vorher die citation aus der antwort mail
en~~
next time I remove the email citation

jue89 requested a review from kfessel October 21, 2022 15:29

jue89 requested review from leandrolanzieri, jia200x and MrKevinWeiss as code owners October 21, 2022 15:29

github-actions bot added Area: Kconfig Area: Kconfig integration Area: sys Area: System Area: timers Area: timer subsystems labels Oct 21, 2022

jue89 requested a review from kaspar030 October 21, 2022 15:30

jue89 added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Oct 24, 2022

github-actions bot added the Area: CI Area: Continuous Integration of RIOT components label Oct 24, 2022

kfessel reviewed Oct 25, 2022

View reviewed changes

MrKevinWeiss requested changes Oct 25, 2022

View reviewed changes

sys/ztimer/Kconfig Outdated Show resolved Hide resolved

github-actions bot added Area: boards Area: Board ports and removed Area: CI Area: Continuous Integration of RIOT components labels Oct 26, 2022

kfessel reviewed Oct 27, 2022

View reviewed changes

jue89 added 2 commits October 27, 2022 19:44

sys/ztimer: add defaults for ztimer_periph_lptimer

159749e

sys/ztimer: build ztimer_periph_timer if ztimer_periph_lptimer is used

bd60324

ztimer_periph_lptimer is uses the implementation of ztimer_periph_timer

jue89 force-pushed the fix/ztimer_lptimer_kconfig branch from 3662eea to da0d37d Compare October 27, 2022 17:45

jue89 mentioned this pull request Oct 27, 2022

ztimer: add ztimer_ondemand module for implicit power management #17607

Merged

MrKevinWeiss approved these changes Nov 1, 2022

View reviewed changes

kfessel reviewed Nov 1, 2022

View reviewed changes

boards/xg23-pk6068a: provide ZTIMER_LPTIMER configuration

ef3e192

jue89 force-pushed the fix/ztimer_lptimer_kconfig branch from da0d37d to ef3e192 Compare November 1, 2022 13:26

MrKevinWeiss reviewed Nov 1, 2022

View reviewed changes

jue89 merged commit 84c89f9 into RIOT-OS:master Nov 2, 2022

jue89 deleted the fix/ztimer_lptimer_kconfig branch November 2, 2022 12:56

kaspar030 added this to the Release 2023.01 milestone Jan 19, 2023

sys/ztimer: model ztimer_periph_lptimer for Kconfig #18783

sys/ztimer: model ztimer_periph_lptimer for Kconfig #18783

Conversation

jue89 commented Oct 21, 2022 • edited Loading

Contribution description

Testing procedure

With Kconfig support

Without Kconfig support

Issues/PRs references

riot-ci commented Oct 21, 2022 • edited Loading

Murdock results

Artifacts

MrKevinWeiss commented Oct 24, 2022

jue89 commented Oct 24, 2022

kfessel commented Oct 25, 2022

kfessel left a comment

Choose a reason for hiding this comment

MrKevinWeiss commented Oct 25, 2022

MrKevinWeiss commented Oct 25, 2022

jue89 commented Oct 25, 2022

MrKevinWeiss commented Oct 25, 2022

kfessel commented Oct 25, 2022 • edited Loading

MrKevinWeiss commented Oct 25, 2022

jue89 commented Oct 26, 2022

MrKevinWeiss commented Oct 27, 2022

jue89 commented Oct 27, 2022

jue89 commented Oct 27, 2022

MrKevinWeiss commented Oct 27, 2022

jue89 commented Oct 27, 2022

leandrolanzieri commented Oct 27, 2022

leandrolanzieri commented Oct 27, 2022

MrKevinWeiss commented Oct 27, 2022

MrKevinWeiss commented Oct 27, 2022

kfessel Oct 27, 2022

Choose a reason for hiding this comment

kfessel Oct 27, 2022

Choose a reason for hiding this comment

jue89 Oct 27, 2022

Choose a reason for hiding this comment

kfessel Oct 27, 2022 • edited Loading

Choose a reason for hiding this comment

jue89 Oct 27, 2022 • edited Loading

Choose a reason for hiding this comment

jue89 commented Nov 1, 2022

MrKevinWeiss left a comment

Choose a reason for hiding this comment

kfessel left a comment

Choose a reason for hiding this comment

kfessel Nov 1, 2022 • edited Loading

Choose a reason for hiding this comment

jue89 Nov 1, 2022 • edited Loading

Choose a reason for hiding this comment

kfessel Nov 1, 2022

Choose a reason for hiding this comment

MrKevinWeiss left a comment

Choose a reason for hiding this comment

MrKevinWeiss Nov 1, 2022

Choose a reason for hiding this comment

jue89 Nov 1, 2022

Choose a reason for hiding this comment

jue89 commented Nov 2, 2022

kfessel commented Nov 2, 2022 via email

jue89 commented Nov 2, 2022

kfessel commented Nov 2, 2022

jue89 commented Oct 21, 2022 •

edited

Loading

riot-ci commented Oct 21, 2022 •

edited

Loading

kfessel commented Oct 25, 2022 •

edited

Loading

kfessel Oct 27, 2022 •

edited

Loading

jue89 Oct 27, 2022 •

edited

Loading

kfessel Nov 1, 2022 •

edited

Loading

jue89 Nov 1, 2022 •

edited

Loading