Add Harbor NXT proposal

[bupd]

Summary

Proposes creating goharbor/harbor-nxt as an official incubation repository for experimental features with lower contribution barriers and a clear graduation path to core Harbor.

Problem

• Experimental features face high scrutiny, slowing innovation
• Contributors develop in private forks, limiting visibility and collaboration
• No official space for promising ideas to mature collaboratively

Solution

• Dedicated incubation space with lower contribution barriers
• Frequent upstream syncs (daily to biweekly) to prevent divergence
• Clear graduation criteria: 30+ days stability, test coverage, documentation
• 6-month archival policy for stalled features

Example Incubation Candidates

• Distribution v3 Integration
• Official ARM Builds
• Podman Support
• Playwright Test Migration
• Scratch/Distroless Images

Governance

• Semi-autonomous from core Harbor
• NXT maintainers handle day-to-day operations
• Core maintainers retain graduation decision authority
• Initial maintainer: @Vad1mo

[reasonerjt]

@bupd Thanks for the proposal.

My concern is that there may be too many new things added to the repo and we end up find it's not possible to merge the changes to current harbor repo.

How is adding a new repo different from creating a branch like topic/nxt/xxxx in goharbor/harbor and collaborating on that?

[Vad1mo]

My concern is that there may be too many new things added to the repo and we end up find it's not possible to merge the changes to current harbor repo.

There is no obligation to "merge"
Harbor Nxt should be the place where features can mature and grow to be included in Harbor. Features can also remain in NXT forever or be removed.

How is adding a new repo different from creating a branch like topic/nxt/xxxx in goharbor/harbor and collaborating on that?

• Only existing Harbor committers can push; adding new contributors requires granting access to entire codebase
• The NXT repo can be opened up to a bigger contributor audience; currently, Harbor is dominated by one organization.
• Dedicated issues, discussions, and project boards for experimental work
• Clear, visible home for innovation
• Much easier to create builds consisting of multiple features. Users can assemble and test builds combining multiple experimental features (e.g., ARM + Podman + Distribution v3)

[reasonerjt]

@Vad1mo

There is no obligation to "merge"

There may be a misunderstanding, but I disagree with this. Let's discuss via Zoom or in the community meeting to make sure we are aligned.

[reasonerjt]

@Vad1mo

I'm blocking this one from being merged accidentally.

Let's discuss to make sure we are aligned.

[renmaosheng]

@Vad1mo If we only want to enable experimental feature, we should develop a framework to allow us to deliver the experimental feature instead of creating a new repo completely. My opinion is we should always working on the single repo.