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

Maintenance of k*-ecosystem #1861

Open
h-vetinari opened this issue Dec 11, 2022 · 12 comments
Open

Maintenance of k*-ecosystem #1861

h-vetinari opened this issue Dec 11, 2022 · 12 comments

Comments

@h-vetinari
Copy link
Member

h-vetinari commented Dec 11, 2022

There are more than 30 packages stuck in the qt 5.15 migrator, which seem to be leading up to https://github.com/conda-forge/kdenlive-feedstock.

Most of these feedstocks seem to have been added by @scopatz, and only have him as a maintainer. There are many, many open version bump and migrator PRs across those feedstocks, and the final package has ~6k downloads.

Should these feedstocks be archived? Or is there someone willing to maintain them?

@ocefpaf
Copy link
Member

ocefpaf commented Dec 11, 2022

Should these feedstocks be archived?

Archiving makes it harder to find new maintainers. If a way, the "abandoned" status, is an open invitation to a new maintainer while archived means we don't want those anymore.

Or is there someone willing to maintain them?

We should probably advertise that. In the Linux world they usually email the community with a "packages for adoption" list.

@jaimergp
Copy link
Member

Repos can have labels, so maybe we can come up with a suitable one that the bots can query for in case they need to be ignored.

For example:

  • abandoned, but sounds too pessimistic
  • maintainer-needed
  • inactive

(This could be part of a bigger conversation about feedstock "health status" and how to attach the corresponding metadata).

@ocefpaf
Copy link
Member

ocefpaf commented Dec 14, 2022

This could be part of a bigger conversation about feedstock "health status" and how to attach the corresponding metadata.

We had this conversation in the past and never reached a consensus. I like those label but I'd drop inactive. In a way that is the only thing we do when we archive a feedstock. The other two labels could be useful but I'd keep only maintainer-needed. In a way, many "abandoned" feedstock still get infrastructure updates and migrations, so they are never really abandoned.

@jaimergp
Copy link
Member

Oh, yes, I've found this issue. There might be others.

Users have been submitting some feedstocks they've found with reduced activity there; maybe we can add the k-* ecosystem there as well?

@h-vetinari
Copy link
Member Author

Regardless of how we advertise the takeover of these feedstocks, I suggest we close the qt5.15 PRs for them - progressing on qt is hard enough as it is without having 30 abandoned feedstocks in the mix.

For reference, here is the graph from the bot of how these packages depend on each other (and thus the build order if someone wants to pick this up later):

image

@jakirkham
Copy link
Member

Can we just leave them open and ignore them? The problem with closing them is the migrator thinks they are done and can then migrate their dependencies, which won't be possible since these packages themselves are not migrated then

@h-vetinari
Copy link
Member Author

The problem with closing them is the migrator thinks they are done and can then migrate their dependencies, which won't be possible since these packages themselves are not migrated then

Which is why I'm proposing to close the PRs for the entirety of that interconnected blob of dependencies in the graph above. Keeping them open makes it seem like we're still miles away with the qt 5.15 migration, when realistically only a few packages are missing. It would allow us to focus efforts to get this over the finish line, rather than waiting in artificial stasis until someone comes along to fix an ecosystem of packages with <10k downloads.

qt6 is making big strides in conda-forge, and moving to that is predicated on finishing the 5.15 migration. I don't think we should block such crucial packages (or any migration, really) on feedstocks that aren't actively being maintained.

@jakirkham
Copy link
Member

Think we can take the fact that these feedstocks are unmaintained into consideration when determining whether or not to close out the migration. We've needed to make similar calls for migrations where even maintained feedstocks could not integrate them for other reasons (upstream changes needed, new release, etc.). So think we could do similar here.

@beckermr
Copy link
Member

beckermr commented Aug 7, 2023

@h-vetinari Maybe we could add a feature to the bot to skip/ignore/always issue migrations for certain feedstocks?

@h-vetinari
Copy link
Member Author

h-vetinari commented Aug 9, 2023

Maybe we could add a feature to the bot to skip/ignore/always issue migrations for certain feedstocks?

I put a 👍 because I think it would be OK to do it like that, but I think it's just delaying the inevitable. Switching off migrations is IMO an explicit admission that the feedstocks are dead and gone.

I've never really understood the concerns about archiving unmaintained feedstocks generally1, but in this particular case it should be on the table IMO, as it's exceedingly unlikely that anyone ever would want to sign up for reviving a set of 30+ interconnected feedstocks that haven't been built in years, for a very niche (in conda-forge) stack. And in the unlikely event that such a k-messiah does come a long, we still would only have to unarchive them.

Footnotes

  1. it can easily be undone, and we could leave a message in the README that anyone interested in picking up maintenance should open a PR to admin-requests for exactly that

@xhochy
Copy link
Member

xhochy commented Sep 29, 2023

Seeing them pop up everywhere (not-solvable in migrations, bot errors somewhere and errored version updates), I would be very much in favor of archiving all of them. For such a large ecosystem, if someone shows up that would like to maintain them again, I would expect that they have had probably contact with one of the other ways of conda-forge already to ask how they can be unarchived.

@h-vetinari
Copy link
Member Author

Given that the last comment to archive the k* ecosystem wholesale has 5 👍's from core1, should we reconsider this?

Footnotes

  1. including Uwe as the author of the comment, not including Silvio

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

No branches or pull requests

6 participants