You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally the odh-manifests repo was the source of truth for every component that was deployed in ODH since we defaulted to the Kubeflow model of using a single forked gitops mono-repo to customize and deploy all of the ODH components. Now that each ODH component has it's own repo under opendatahub-io, the operator has been redesigned and we are using the opendatahub-community/issues board as the initial issue tracking board tracking issues in odh-manifests has been made obsolete and redundant.
We need to disable issues in odh-manifests and redirect all Open Data Hub issues to opendatahub-community/issues as the unified. Any feedback (bugs, features, ...) with ODH deployment or installation, should be tracked in opendatahub-operator/issues. Other issues related to component functionality will be redirected to opendatahub-community/issues or the affected component.
Additional Info
GitHub supports linking issues to pull requests across repositories in an org. So there is no loss of builting GitHub issue automation when specifying that a PR in repository ABC Closes opendatahub-io/repository-XYZ#789
Originally the odh-manifests repo was the source of truth for every component that was deployed in ODH since we defaulted to the Kubeflow model of using a single forked gitops mono-repo to customize and deploy all of the ODH components. Now that each ODH component has it's own repo under opendatahub-io, the operator has been redesigned and we are using the opendatahub-community/issues board as the initial issue tracking board tracking issues in odh-manifests has been made obsolete and redundant.
We need to disable issues in odh-manifests and redirect all Open Data Hub issues to opendatahub-community/issues as the unified. Any feedback (bugs, features, ...) with ODH deployment or installation, should be tracked in opendatahub-operator/issues. Other issues related to component functionality will be redirected to opendatahub-community/issues or the affected component.
Additional Info
GitHub supports linking issues to pull requests across repositories in an org. So there is no loss of builting GitHub issue automation when specifying that a PR in repository ABC
Closes opendatahub-io/repository-XYZ#789
See Linking a pull request to an issue using a keyword
The text was updated successfully, but these errors were encountered: