[kata-dev] Elections | Q&A | What are the current pain points with the AC and how to solve them?

Eric Ernst eric.g.ernst at gmail.com
Mon Nov 14 19:57:37 UTC 2022


Hey Fabiano,

I don't feel there are that many challenges with respect to the
architecture committee *itself* to day, as we haven't had a ton of need to
specifically exercise it. I think if we step back and look at the Kata
Containers community itself, I can think of a few areas we can highlight as
challenges:
1) Time zones, daylight savings
2) Participation - online and offline.
3) Reviews
4) Non core-code contributions
5) Varied views on what is important for the project

(1) is mostly a joke, but seriously.  For (2), this is somewhat a response
to (1). We have contributors spread across all timezones, which makes
regular live collaboration a challenge. For me, I know I can either stay up
late and catch our friends in APAC, or wake up early to get more cycles
with our EU partners. I think that while the AC meeting calls are a great
forcing function to meet, we need to make sure we are effective at getting
attention and collaboration on issues offline as well -- for example though
GitHub issues. This should be the primary communication as it'll allow for
the most community equity (time and langauge), as well as a good forcing
function to ensure we have a higher level of collaboration in place so the
AC calls are as effective as possible.

For (3) -- I feel guilty of this, but we need to make sure we all make time
for helping with reviews.

For (4) -- we have been very reliant on a few heros to make sure our "less
shiny" code that keeps the project stable is maintained. While it has
improved, I worry that we need to have more contributors to our CI and CD
infrastructure.

For (5) -- As each group has their own use cases for Kata Containers, there
are naturally different views on what is top priority for the project. As
an example, I am very tied at the moment to the Go implementation of the
kata shim - as a result all of my development and fixes are against this.
Knowing I will need to migrate to another implementation in the future is a
stress-point for me, and a risk for my usage. Having said that, I know
*not* migrating is also a risk, as a large percentage of our users are
focusing on the rust shim.  This is a trade-off, and knowing that we need
to plan for and accommodate such conflicting priorities is a big part of
driving this project.

-Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.katacontainers.io/pipermail/kata-dev/attachments/20221114/daab7fa8/attachment.htm>


More information about the kata-dev mailing list