[META] Is this project still properly maintained ?

[HorlogeSkynet]

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 :

• there has not been a release for more than a year : 1.5.0 was released on 2020-03-31
• only two small pull requests have been merged in the last year (Detect distro from arbitrary rootfs root_dir #161 #247, catch and ignore subprocess.CalledProcessError when running lsb_relsase #261)
• you have acknowledgment to "hardly have any capacity to deal with issues nowadays" and your GitHub profile bio lists multiple other likely time-intensive responsibilities
• there are multiple @nir0s mentions that have not received a reply until today (e.g. in catch and ignore subprocess.CalledProcessError when running lsb_relsase #261 and Honors /usr/lib/os-release when /etc/os-release is not available #262)
• there are 30 open issues and 8 open pull requests today

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]

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]

Up @nir0s.

[nir0s]

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

…

On Sat, Jun 26, 2021, 17:09 Samuel FORESTIER ***@***.***> wrote: Up @nir0s <https://github.com/nir0s>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#274 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPJBBHISFSLO4FVHSIN7SLTUXNRJANCNFSM457GW2GQ> .

[hartwork]

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

@nir0s any news?

[nir0s]

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]

• 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]

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]

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]

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]

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

[funkyfuture]

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]

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

[adamjstewart]

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]

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]

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.)