Skip to content
New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom

[META] Is this project still properly maintained ? #274

Closed
HorlogeSkynet opened this issue Jun 2, 2021 · 27 comments
Closed

[META] Is this project still properly maintained ? #274

HorlogeSkynet opened this issue Jun 2, 2021 · 27 comments

Comments

@HorlogeSkynet
Copy link
Member

Hi @nir0s, hi watchers,

Like ~15.000+ others, I depend on distro and I have come to be concerned about the state of the project, because :

So please find below some questions I would want to ask you :

  • are you planning to work again in the near future on this project ?
  • would you consider "moving" the repository (as long as PyPI access) to someone you trust and willing/doing its best to maintain it ?
  • would you turn this project into a GitHub organization (and grant some volunteers rights to it), so as to facilitate external contributions while keeping all the metadata and PyPI access ?
  • would you encourage forking or re-writing distro as a new independent project ?

Thanks for reply 🙏
@brejoc
Copy link
Member

brejoc commented Jun 6, 2021 •
edited
Loading

While fmpov spreading the burden of maintenance over several shoulders would be a good solution, this begs one question: Do we have a group of people that can be trusted with this and would be willing do to it?

PS: Thanks for opening this issue, @HorlogeSkynet. I was also thinking about addressing this soon.

@HorlogeSkynet
Copy link
Member Author

Up @nir0s.

@nir0s
Copy link
Collaborator

nir0s commented Jun 26, 2021 via email

@hartwork
Copy link
Contributor

Hey all, I will reply later today to get this going.

@nir0s any news?

@nir0s
Copy link
Collaborator

nir0s commented Jun 30, 2021 •
edited
Loading

Hey. Got some issues lately.

Anyway, there's indeed no way I'm going to keep maintaining this myself. I'll try to answer all of @HorlogeSkynet's questions:

  • I would like to maintain it, but no, I don't intend on doing so.
  • I'd happily add maintainers to PyPI.
  • Unless everyone sees a GitHub organization as valuable within itself, I'm not sure I'd like that. This is a small project, and I'm not sure that it warrants its own org. Thoughts?
  • I guess that if maintainers are added, there's no reason to create a fork.

The only question that stands now from my POV is who the contributors are.

@hartwork
Copy link
Contributor

  • Unless everyone sees a GitHub organization as valuable within itself, I'm not sure I'd like that. This is a small project, and I'm not sure that it warrants its own org. Thoughts?

What an org would allow the distro project is to better signal that it's been turned into a community effort where a group does the work rather than one key individual, and that there door is open for new people. Membership would become something well visable, rather than something to be found when looking. Also, in a single repo you would remain a bottleneck on repository permissions to my understanding, and an org would fix that midterm. What do you think?

@HorlogeSkynet
Copy link
Member Author

The only question that stands now from my POV is who the contributors are.

As I said here, I would be able to, but not alone.

What an org would allow the distro project is to better signal that it's been turned into a community effort [...].

👍

Also, in a single repo you would remain a bottleneck on repository permissions to my understanding [...].

I guess finely tuned GitHub permissions + pull requests rules could workaround that.

Quick poll: hey @brejoc @andy-maier @sethmlarson @asottile @funkyfuture @MartijnBraam @pombredanne @adamjstewart, would you enroll as a "contributor" here (sorry for the noises) ?

Bye 👋

@brejoc
Copy link
Member

brejoc commented Jun 30, 2021

I have to admit that I would also be in favour of an organization. Makes things more visible, easier to find and last but not least to organize. python-distro might be comparatively small in size, but it's an important project. Many other packages rely on it and in my case a small change broke Debian builds for the openSUSE build service. So it's one of those packages that should have eyes from several people and ideally several distros. I'm not sure how much time I can invest, but I would be happy to help!

@adamjstewart
Copy link
Contributor

I'm not sure how much bandwidth I would have to help maintain distro, but I definitely rely on it. The Spack package manager completely depends on distro to detect the host OS. We've opened a few issues/PRs over the years to fix detection issues our users have reported. I'll see if any other Spack developers would be interested.

@hartwork
Copy link
Contributor

If this becomes a community effort, I'd be happy to see how I can help.

@funkyfuture
Copy link
Contributor

funkyfuture commented Jun 30, 2021 •
edited
Loading

i also have a limited amount of time available and i find this project essential for the Python community. hence, a few thoughts:

what i can offer is to act as reviewer on pull requests. not always, but i guess this is doable often for me.

it might make things easier in the long term if people involved in distributions (likely maintaining Python packages for it) get involved to keep an eye on their concerns.

i generally find it helpful when a project publishes a consensus about the criteria of Python versions that it supports. (yes, this does not directly concern the maintenance of the package, but i find that helpful when both contributing and maintaining.)

addendum: oh, and it would be super cool if someone could draft a document that describes the intended change of mode.

@sethmlarson
Copy link
Contributor

Having contributed in the past I'd be willing to contribute again, especially if I had commit bit.

@adamjstewart
Copy link
Contributor

i generally find it helpful when a project publishes a consensus about the criteria of Python versions that it supports. (yes, this does not directly concern the maintenance of the package, but i find that helpful when both contributing and maintaining.)

In particular, Spack has really annoying Python support requirements. A lot of clusters we run on still only have Python 2.6 so we're actively maintaining Python 2.6 support. We're stuck on an old version of distro that still supports Python 2.6. If we got involved in distro maintenance we might want to re-add support for 2.6, or at least ensure that 2.7 support doesn't go away for the foreseeable future.

@nir0s
Copy link
Collaborator

nir0s commented Jun 30, 2021

Alright then. I've created the python-distro org (https://github.com/python-distro), and I'm now moving this project over to that org. I've already added everyone on this thread to the org, and we can decide on permissions later.

I can certainly draft something that would convey how this is going to be managed from now on. I do, however, wonder if the org can encapsulate more than just this project, as we had previous features in mind that could provide benefits beyond just what distro does right now. That'

s beside the point, though.

@hartwork
Copy link
Contributor

i generally find it helpful when a project publishes a consensus about the criteria of Python versions that it supports. (yes, this does not directly concern the maintenance of the package, but i find that helpful when both contributing and maintaining.)

In particular, Spack has really annoying Python support requirements. A lot of clusters we run on still only have Python 2.6 so we're actively maintaining Python 2.6 support. We're stuck on an old version of distro that still supports Python 2.6. If we got involved in distro maintenance we might want to re-add support for 2.6, or at least ensure that 2.7 support doesn't go away for the foreseeable future.

@adamjstewart I consider that rather off-topic and controversial. I'm in some conflict here now because if I reply to that I contribute to taking things off-topic more but if I don't I let your statement sit here without justified protest and that does not seem healthy either. So I will do a quick reply and ask you to create a dedicated ticket for discussion if you insist this matters. Does that sounds fair?
(My comment about Python 2.6 is that I will personally pull the veto card on this if I can, because all versions of Python before 3.6 are end-of-life today and the community is the wrong place and shoulder to maintain a museum: That's something that the enterprise can do in their own garden on their bill. The problem is the user of distro in that case, and that side should change.)

@hartwork
Copy link
Contributor

hartwork commented Jun 30, 2021 •
edited
Loading

Alright then. I've created the python-distro org (https://github.com/python-distro), and I'm now moving this project over to that org. I've already added everyone on this thread to the org

@nir0s awesome, thank you! 🎉 🙏

@hartwork
Copy link
Contributor

@nir0s at least one more trusted PyPI maintainer would be great, now or soon-ish. If you're looking for usernames up there:

@sethmlarson
Copy link
Contributor

sethmlarson commented Jun 30, 2021 •
edited
Loading

@nir0s Instead of adding anyone to PyPI, can you hang on the line for a little longer and instead one day create a PyPI API token and continuous deployment which requires multiple maintainers to approve for a deploy to happen? I think this is the most security conscious way to handle a package which receives this amount of downloads.

I can work on the continuous deployment via GitHub Actions and then you'd only need to set a secret within GitHub.

@nir0s
Copy link
Collaborator

nir0s commented Jun 30, 2021 via email

@sethmlarson
Copy link
Contributor

@nir0s See #275 for my proposal.

@pombredanne
Copy link
Contributor

@HorlogeSkynet re:

would you enroll as a "contributor" here (sorry for the noises) ?

Sure thing. FWIW I ended up building my own distro detector using only os-release files at https://github.com/nexB/container-inspector/blob/main/src/container_inspector/distro.py and I am adding support for FreeBSD and Windows too eventually.

And I have also aggregated and merged several collections of os-release files for testing in https://github.com/nexB/container-inspector/tree/main/tests/data/distro/os-release and this is likely the largest collection anywhere now :)

If this code can help here I would be glad to contribute. I can also consider using this project if there is a way to work exclusively off any rootfs on any OS and never execute a commands using os-release files and similar like I do in my code.

@asottile
Copy link
Contributor

asottile commented Jun 30, 2021 •
edited
Loading

would you enroll as a "contributor" here (sorry for the noises) ?

EDIT: (sorry for premature enter)

I would, though I'm afraid I already maintain too many things (and I personally no longer directly use distro -- my last project which used it was recently sunset)

happy to assist in other ways though 👍

@nir0s
Copy link
Collaborator

nir0s commented Jul 1, 2021

@pombredanne, I'd happily add you as a maintainer and would be happy to receive that contribution.

@nir0s
Copy link
Collaborator

nir0s commented Jul 1, 2021

@asottile, that's fine. We all have lives :)

@HorlogeSkynet
Copy link
Member Author

Have we properly dealt with all raised points ? Can we close this issue and keep on with the PRs and so on ? 😏

@HorlogeSkynet
Copy link
Member Author

Let's close this then, thank you all for your time and commitment 🙇

@sethmlarson
Copy link
Contributor

Just had our first successful end-to-end release of distro under the new organization! 🎉

PyPI: https://pypi.org/project/distro
GitHub Release: https://github.com/python-distro/distro/releases/tag/v1.6.0

# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@brejoc @pombredanne @hartwork @asottile @nir0s @funkyfuture @HorlogeSkynet @adamjstewart @sethmlarson