Proposal: Rename Repository to dra-driver-nvidia-gpu

[shivamerla]

@pohly initiated a discussion here proposing that the repository be renamed to dra-driver-nvidia-gpu.

This issue is being created to continue that discussion, align on a consistent naming convention for this repository, and establish guidelines that can be applied to future vendor-specific DRA drivers donated. cc @klueska @dims @jgehrcke @johnbelamaric

[pohly]

The rationale for my proposal is the naming scheme in kubernetes/org#5597 (comment): <vendor>-dra-driver-<class>

<vendor> doesn't necessarily imply "selling". The more important aspect is that the vendor makes something available and is responsible for it.

What NVIDIA donated was the "NVIDIA DRA Driver for GPUs" (NVIDIA as vendor of the driver). What it became as part of the donation is the "Kubernetes DRA Driver for NVIDIA GPUs" (Kubernetes as vendor, "NVIDIA GPUs" as the class of devices). This leads to "kubernetes-sigs/dra-driver-nvidia-gpu" as repository name. The README.md also needs to be updated to make it clear who's releasing the driver.

[shivamerla]

This completely makes sense. I will wait for @klueska @dims @johnbelamaric @jgehrcke to chime in before we make the official request for renaming.

[johnbelamaric]

+1 Patrick's rationale makes sense to me

[dims]

I'll go last! want everyone to chime in :)

[jgehrcke]

Kubernetes DRA Driver for NVIDIA GPUs
dra-driver-nvidia-gpu

Great. Consensus and consistency are the most important principles here. Do any alternatives come to mind that are also worth considering? If not, we have our new name(s) (short form, long form).

[klueska]

This makes sense to me as well. Keep in mind it is more than just a rename of the repo though. The name of the Module, container image, helm chart, etc. will also need to be changed.

There was talk at some point of changing the versioning scheme away from calendar versioning.

If we want, we can piggyback the opportunity to do that here since we are changing the helm chart / image name.

That would make the next release 0.4.0, with aliases created for the previous releases as follows:

0.1.0 --> 25.3.0
0.2.0 --> 25.8.0
0.3.0 --> 25.12.0

[pohly]

The name of the Module, container image, helm chart, etc. will also need to be changed.

Release artifacts will be under a different location anyway, won't they?

[klueska]

Yes. Im just highlighting that there are code changes necessary to ensure the name of the artifacts produced are consistent with the new repo name, not the old name.

[guptaNswati]

well it could be gpu-dra-driver-nvidia but probably it does not comply with <vendor>-dra-driver-<class>

[guptaNswati]

This makes sense to me as well. Keep in mind it is more than just a rename of the repo though. The name of the Module, container image, helm chart, etc. will also need to be changed.

There was talk at some point of changing the versioning scheme away from calendar versioning.

If we want, we can piggyback the opportunity to do that here since we are changing the helm chart / image name.

That would make the next release 0.4.0, with aliases created for the previous releases as follows:

0.1.0 --> 25.3.0 0.2.0 --> 25.8.0 0.3.0 --> 25.12.0

+++1 to this. we should move to SemVer as part of this effort where all components can be updated in one go.

[shivamerla]

This makes sense to me as well. Keep in mind it is more than just a rename of the repo though. The name of the Module, container image, helm chart, etc. will also need to be changed.

Ack, we might also need to update the image registries, google group and job configurations here and here.

[dims]

Let's give it a few more days to see if anyone else wants to chime in.

[shivamerla]

There was talk at some point of changing the versioning scheme away from calendar versioning.

If we want, we can piggyback the opportunity to do that here since we are changing the helm chart / image name.

That would make the next release 0.4.0, with aliases created for the previous releases as follows:

0.1.0 --> 25.3.0 0.2.0 --> 25.8.0 0.3.0 --> 25.12.0

Yes, this will solve the Go module versioning issue described here. Going forward, clients will be able to import packages without us having to bump the module version.

One caveat is that upgrades from existing downstream Helm charts published in NGC won’t work seamlessly. Because 0.4.0 is lower than 25.12.0, Helm will treat it as a downgrade, so users will need to explicitly specify the chart version during upgrade.