Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature] Should we move components to a new repository? #11145

Open
diegolovison opened this issue Aug 28, 2024 · 2 comments
Open

[feature] Should we move components to a new repository? #11145

diegolovison opened this issue Aug 28, 2024 · 2 comments

Comments

@diegolovison
Copy link
Contributor

Feature Area

/area components

What feature would you like to see?

The overall idea of this issue is to discuss the pros and cons of keeping https://github.com/kubeflow/pipelines/tree/master/components inside kubeflow/pipelines or moving to a new repository.

We are expecting each company RH/Google/others to explain their opinions to have a final agreement.

@HumairAK
Copy link
Collaborator

Today's KFP call, @chensun et al preferred to keep the components folder around.

I would like to see us take a more aggressive stance on removing unmaintained components. IMO we should identify components that are:

  1. Very old
  2. Unmaintained

And just remove these from the repo. Keeping them around adds tech debt that we do not have the bandwidth to maintain today. I suggest removing the following folders in https://github.com/kubeflow/pipelines/tree/master/components:

  • ibm-components
    • this is empty
  • azure
    • has not been updated in 3 years
  • great-expectations/validate
    • has not been updated in 3 years
  • local
    • has not been updated in 3 years

I'm not sure what the intention of contrib folder was, but it also has not been touched in a long time, and we should consider moving it. My preference is to simply remove these folders and not put them in any sort of archived type folder.

@diegolovison
Copy link
Contributor Author

@chensun no updates from your side. I think it is fine and we can start by removing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants