---
# System prepended metadata

title: 'Spotlight on SIG Architecture: Code Organization'

---

---
layout: blog
title: "Spotlight on SIG Architecture: Code Organization"
slug: sig-architecture-code-org-2024
date: 2024-03-13
author: "Frederico Muñoz (SAS Institute)"
---


_This is the third interview of a SIG Architecture Spotlight series that will cover the different subprojects. We will cover the [SIG Architecture: Code Organisation](https://github.com/kubernetes/community/blob/master/sig-architecture/README.md#code-organization-1)_

In this SIG Architecture spotlight we talked with [Madhav Jivrajan](https://github.com/MadhavJivrajani) (VMware), a member of the Code Organization subproject. 

## Introducing the Code Organization subproject

**Frederico (FSM)**: Hello Madhav, thank you for your availability. Could we start by telling us a bit about yourself, your role and how you got involved in Kubernetes?

**Madhav Jivrajani (MJ)**: Hello! My name is Madhav Jivrajani, I serve as a technical lead for SIG Contributor Experience and a GitHub Admin for the Kubernetes project. Apart from that I also contribute to SIG API Machinery and SIG Etcd, but more recently, I’ve been helping out with the work that is needed to help Kubernetes [stay on supported versions of Go](https://github.com/kubernetes/enhancements/tree/cf6ee34e37f00d838872d368ec66d7a0b40ee4e6/keps/sig-release/3744-stay-on-supported-go-versions), and it is through this that I am involved with the Code Organization subproject of SIG Architecture.

**FSM**: A project the size of Kubernetes must have unique challenges in terms of code organization -- is this a fair assumption?  If so, what would you pick as some of the main challenges that are specific to Kubernetes?

**MJ**: That’s a fair assumption! The first interesting challenge comes from the sheer size of the Kubernetes codebase. We have ~2.2 million lines of Go code (which is steadily decreasing thanks to [dims](https://github.com/dims) and other folks in this sub-project!), and a little over 240 dependencies that we rely on either directly or indirectly, which is why having a sub-project dedicated to helping out with dependency management is crucial: we need to know what dependencies we’re pulling in, what versions these dependencies are at, and tooling to help make sure we are managing these dependencies across different parts of the codebase in a consistent manner.

Another interesting challenge with Kubernetes is that we publish a lot of Go modules as part of the Kubernetes release cycles, one example of this is [`client-go`](https://github.com/kubernetes/client-go).However, we as a project would also like the benefits of having everything in one repository to get the advantages of using a monorepo, like atomic commits... so, because of this, code organization works with other SIGs (like SIG Release) to automate the process of publishing code from the monorepo to downstream individual repositories which are much easier to consume, and this way you won’t have to import the entire Kubernetes codebase!

## Code organization and Kubernetes

**FSM**: For someone just starting contributing to Kubernetes code-wise, what are the main things they should consider in terms of code organization? How would you sum up the key concepts?

**MJ**: I think one of the key things to keep in mind at least as you’re starting off is the concept of staging directories. In the [`kubernetes/kubernetes`](https://github.com/kubernetes/kubernetes) repository, you will come across a directory called [`staging/`](https://github.com/kubernetes/kubernetes/tree/master/staging). The sub-folders in this directory serve as a bunch of pseudo-repositories. For example, the [`kubernetes/client-go`](https://github.com/kubernetes/client-go) repository that publishes releases for `client-go` is actually a [staging repo](https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/client-go). 

**FSM**: So the concept of staging directories fundamentally impact contributions?

**MJ**: Precisely, because if you’d like to contribute to any of the staging repos, you will need to send in a PR to its corresponding staging directory in `kubernetes/kubernetes`, once the code merges there, we have a bot called the [`publishing-bot`](https://github.com/kubernetes/publishing-bot) that will sync the merged commits to the required staging repositories (like `kubernetes/client-go`). This way we get the benefits of a monorepo but we also can modularly publish code for downstream consumption. PS: The `publishing-bot` needs more folks to help out!

For more information on staging repositories, please see the [contributor documentation](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/staging.md).

**FSM**: Speaking of contributions, the very high number of contributors, both individuals and companies, must also be a challenge: how does the subproject operate in terms of making sure that standards are being followed?

**MJ**: When it comes to dependency management in the project, there is a [dedicated team](https://github.com/kubernetes/org/blob/a106af09b8c345c301d072bfb7106b309c0ad8e9/config/kubernetes/org.yaml#L1329) that helps review and approve dependency changes. These are folks who have helped lay the foundation of much of the [tooling](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/vendor.md) that Kubernetes uses today for dependency management. This tooling helps ensure there is a consistent way that contributors can make changes to dependencies. The project has also worked on additional tooling to signal statistics of dependencies that is being added or removed: <code>[depstat](https://github.com/kubernetes-sigs/depstat)</code>

Apart from dependency management, another crucial task that the project does is management of the staging repositories. The tooling for achieving this (`publishing-bot`) is completely transparent to contributors and helps ensure that the staging repos get a consistent view of contributions that are submitted to `kubernetes/kubernetes`.

Code Organization also works towards making sure that Kubernetes [stays on supported versions of Go](https://github.com/kubernetes/enhancements/tree/cf6ee34e37f00d838872d368ec66d7a0b40ee4e6/keps/sig-release/3744-stay-on-supported-go-versions). The linked KEP provides more context on why we need to do this. We collaborate with SIG Release to ensure that we are testing Kubernetes as rigorously and as early as we can on Go releases and working on changes that break our CI as a part of this. An example of how we track this process can be found [here](https://github.com/kubernetes/release/issues/3076).

## Release cycle and current priorities

**FSM**: Is there anything that changes during the release cycle?

**MJ** During the release cycle, specifically before code freeze, there are often changes that go in that add/update/delete dependencies, fix code that needs fixing as part of our effort to stay on supported versions of Go.

Furthermore, some of these changes are also candidates for [backporting](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md) to our supported release branches.

**FSM**: Is there any major project or theme the subproject is working on right now that you would like to highlight?

**MJ**: I think one very interesting and immensely useful change that has been recently added (and I take the opportunity to specifically highlight the work of [Tim Hochin](https://github.com/thockin) on this) is the introduction of [Go workspaces to the Kubernetes repo](https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/4402-go-workspaces). A lot of our current tooling for dependency management and code publishing, as well as the experience of editing code in the Kubernetes repo, can be significantly improved by this change. 

## Wrapping up

**FSM**: How would someone interested in the topic start helping the subproject? 

**MJ**: The first step, as is the first step with any project in Kubernetes, is to join our slack: slack.k8s.io, and after that join the `#k8s-code-organization` channel. There is also a [code-organization office hours](https://github.com/kubernetes/community/tree/master/sig-architecture#meetings) that takes place that you can choose to attend. Timezones are hard, so feel free to also look at the recordings or meeting notes and follow up on slack!

**FSM**: Excellent, thank you! Any final comments you would like to share?

**MJ**: The Code Organization subproject always needs help! Especially areas like the publishing bot, so don’t hesitate to get involved in the `#k8s-code-organization` slack channel.
