REQUEST: Archive repo kubernetes-sigs/hierarchical-namespaces

[enj]

Repository to archive

kubernetes-sigs/hierarchical-namespaces

Repository and/or sig subproject owners that are approving this archival

@kubernetes/sig-auth-leads

When should this be done

Anytime

Additional context for request

Per the Feb 26, 2025 SIG Auth meeting (agenda, recording), we made the decision to archive the hierarchical-namespaces project due to a lack of maintainers and adopters.

cc @kubernetes/sig-auth-leads @micahhausler @aramase @adrianludwin @rjbez17 @srampal @tashimi

[pjonsson]

I don't know anything about Kubernetes or hierarchical-namespaces, but it's @rjbez17 that has been the most active in the repository lately as far as I've seen.

Right now he is taking care of some family emergency (kubernetes-retired/hierarchical-namespaces#408 (comment)), so I suggest giving him some time to respond to this.

And I assume it will be difficult to make releases out of archived repositories, so I would appreciate if you could archive the repository after the next release (which was planned "soon" when the family emergency happened: kubernetes-retired/hierarchical-namespaces#408 (comment)).

[enj]

I suggest giving him some time to respond to this

We have already contacted Ryan and the other maintainers in private before opening this issue. He is aware and supportive of our decision to archive the repo. The same is true for Adrian.

And I assume it will be difficult to make releases out of archived repositories

Anyone is free to fork the repo to build artifacts as desired.

I would appreciate if you could archive the repository after the next release

Per kubernetes-retired/hierarchical-namespaces#402 it is no longer possible to push new images for HNC, and I would prefer not burden Ryan or anyone else with unnecessary work.

[rjbez17]

I ultimately agree with the decision here. I’ve clearly not done a good enough job maintaining this the last few years and for that I apologize. I’ve had more than a few people saying they’ll help without any follow up. @pjonsson if you are willing to sign up for long term maintenance help (you've already helped quite a bit recently, but I know this isn't really your area of expertise) we can think about reconsidering? While looking at what was required to cut a new patch release I quickly realized it was not going to be possible with no one available to approve my PRs as I am currently the only maintainer.

I've never had the luxury of contributing to projects as part of my day job, I've always been 100% volunteering on my own time. Unfortunately my day job and family life have not allowed me as much time as I've had in the past. I would love to keep this project alive and can continue to dedicate some time to it but not without dedicated help.

[ciaccotaco]

@rjbez17 - I’ve never been involved in maintaining a project, but I’d be willing to give it a shot. We use HNC heavily at my company and it would be a shame to see this project go away.

[pjonsson]

@rjbez17 on a personal level that is fine with me, but I need to carve out some time. Let me try to set things in motion tomorrow and get back to you with an answer if I can commit to something. I'm guessing it will take a week for me to get some answers.

[rjbez17]

@enj it seems like we have at least one maybe two people interested in keeping this project alive. What do you need to see on your end to hold off on the archival?

[enj]

@enj it seems like we have at least one maybe two people interested in keeping this project alive. What do you need to see on your end to hold off on the archival?

My recommendation would be to create a new GitHub organization and hard fork the HNC repository to it. Then you are free to organize maintenance with whomever you desire at whatever commitment level is appropriate. This removes responsibility and association from SIG Auth/SRC/k8s/CNCF while also giving you the freedom to self organize.

[pjonsson]

I set things in motion as I said and I just got the answer that people will get back to me next week. I don't have leverage to change that schedule, so I apologize for the delay.

[cristiklein]

@enj What would need to happen to continue maintaining this project under kubernetes-sigs/hierarchical-namespaces? The CNCF is seen as a "quality stamp", so continuing this project under CNCF governance is very desirable for many HNC users.

[pjonsson]

I would like to have the governance parts ironed out before making a long-term commitment, there isn't much of a point for me to spend my time on reviving and then maintaining a project that isn't sufficient for its users.

[enj]

@enj What would need to happen to continue maintaining this project under kubernetes-sigs/hierarchical-namespaces?

IMO that ship has sailed, but @deads2k and @liggitt may have different opinions.

The CNCF is seen as a "quality stamp", so continuing this project under CNCF governance is very desirable for many HNC users.

This is exactly the false belief that I am trying to undo here. kubernetes/kubernetes#131009 is a recent example of what goes wrong when folks think that just because a project is within one of the kubernetes orgs, that is somehow has the same quality and support of k/k itself.

These projects are difficult and time consuming to maintain over time, so they need kube org members to maintain them as part of their regular jobs to be sustainable.

If we take kubernetes-sigs/secrets-store-csi-driver as an example SIG Auth sub project, that project is maintained by multiple kube org members as part of their jobs, and has supported integrations across many vendors (and, therefore, customer relationships that incentivize maintenance). It continues to have regular enhancements as well as releases, including the regular bumps necessary to address CVEs. I do not believe HNC meets this bar.