I’ll point out that “Enterprise” is 21 USD/user/month. That works out to, for the current membership in the PyPA, around 25k/year. If we have 25k USD/year, I really don’t think handing that over to GitHub for slightly faster CI times is the best use of such funding.
And, such a payment model is also incompatible with a “any project can add however many maintainers whenever” model (which is what we have today).
Perhaps we can continue this discussion elsewhere but I think it would be valid to reduce the number of users in the organization and instead give people specific permissions per repository. Adding collaborators to public repositories does not count as a user for billing purposes.
What would be the election cycle? Right now, the entire SC is elected every year, and while that does line up well the the annual release process, I still have a nagging discomfort with the possibility of a full turn over in any election cycle. In order to change that though, terms would have to be extended (you can’t have continuity if all terms are only one year).
I’m not following, do you want to derive the responsibilities of the council from a question of what to document for end users? I think there are more topics that would benefit from an elected council that aren’t end-user problems, but are more about “infrastructure” tasks like maintaining the installers, reviewing PEPs etc. Wondering now if I wrongly used “publications” in my post, I meant everything that is published for end users, including packages, docs, installers etc.
To cater to a constantly evolving packaging ecosystem, my suggestion would be to acknowledge the full extent of what we consider as “packaging” at the moment, when defining the responsibilities of the council, but also allow additional topics to be added via a defined process, such as additional PEPs.
Sorry, I wasn’t clear enough. Those topics are all things that in the past have been suggested as things the PyPA should be making pronouncements (of one form or another) about. To me, that says that people expect the packaging council to have a very wide authority - far wider than I think is either reasonable or practical.
My main point though was simply that I don’t think we have a consensus (or even a good shared understanding!) of what constitutes “packaging”. And I think we need to get that addressed first. For example, your original comment was
I would consider Linux distro packages and conda as “publications of Python maintained by the community”. Are you suggesting that they should follow the same governance process that we’re putting the packaging council in place to manage? Would they agree to that?
Maybe I’m underestimating the community’s willingness to work under a single authority. But to me, this feels like new territory, which is why I’m suggesting that we start with a relatively small scope, and expand when we’ve proved the model works.
Yeah, generally naming discussions are wasteful, it was meant as a scoping point related to @smm’s fourth question. I disagree that the thread you linked would be useful to comment on, given its premise and frankly the pretty eye-rolling linked GitHub issue about the virtues of wheels and conda and pip. Not going to wade into this
FWIW, what I do care about is looking at packaging and distribution problems holistically, instead of the various niches we currently hold on to. It would be really great to empower a group of people to be councilors for all Python users, no matter the used distribution.
Sections to update:
mandate: spelling out the wide scope of “packaging” and “distribution”
roles:
“packaging team” instead of “core team” (initial members: PyPA members)
difference to PyPA, packaging WG, Python core team
relation to 3rd party distributions of Python (goal: partnerships/collaboration)
not sure about the yearly election cycle, would it be useful to stagger it?
Eligible to run for the council: anyone
Eligible to vote: packaging team
Ideal size of the council: 5
Yeah, I’d propose that because the alternative we know (a lack of a governance process like that) led to lots of heartache over the years. The coordination essentially still needed to happen to cater to the demand, just on a per-project level, and was often handled by contributors that had no interest in cross-organizational coordination, who just wanted to work on the software.
I think these distributors would have an incentive to agree to a new governance process like this and become partners in the process, given the increased predictability and transparency, and ability of participation. I think that’s currently missing.
I like this - it’s a much more concrete way of approaching this (far better than where I was going, which was frankly a bad case of overthinking the problem )
There is one key factor that might need sorting out, though, which is PyPA membership. I’m not sure whether the current fairly relaxed approach to how membership is gained is sufficient. Ideally, it’s fine, if we assume everyone’s acting in good faith. But if we get a situation where the council needs to take action to expel someone from the PyPA, things could get tricky.
Why just installers? What about build backends, Warehouse, and other PyPA software?
Also, if we assume PEP 13 as the base, the council should also have the authority to:
Enforce the PyPA CoC
Act as liaison with the PSF around funding and any other areas of shared interest
That’s a good question, I don’t have an answer for
Right, sorry, “maintenance of installers” was in addition to PyPA maintained software, I tacitly assumed PyPA projects would be in the scope of the council, but you’re right, this should be explicitly stated.
So now I’m unclear in the other direction. What “installers” did you mean here if not things like pip? Surely you’re not suggesting that the packaging council gets authority over the python.org installers distributed by the core team? That would be a major conflict with the SC’s responsibility…
Another possibility is voting is done by projects instead of individuals. The SC could be the arbiters of which projects get to vote (much like PEP 13 says the SC can’t change how core devs get added, this would make it so the packaging council can’t choose which projects would get to vote). This opens up the possibility of projects outside of the PyPA org on GitHub to participate, although whether they would want to is another question as the assumption is the projects would be expected to abide by decisions made by the council and they make like their independence.
Indeed, I meant the Python installers distributed on python.org and admittedly, I’m not clear on the details of the conflict of responsibilities with the SC you see. Could you please elaborate?
That’s a reasonable concern, but I’m more concerned about the opposite: making the scope so small that what the council is able to do can’t fix the problems that exist.
I think that is essential. (I would add environment management to packaging and distribution.)
That would be great, although I have some trepidation about how well that would work, given the fairly fundamental differences of opinion that seem to exist so far.
Specific examples aside, the SC could in principle disagree with any decision being taken. To me, this just means that a formation of a python packaging council needs to specify how disagreements with the SC are handled.
Whether that’s a stipulation that the SC has the right to veto anything, a joint vote between the two councils (with some tiebreaking), etc. – as long as there’s a transparent process to reach for if it ever comes up, I’m not worried about such scenarios like 32bit installers.
And realistically, everyone here is working towards the same goal of a vibrant and healthy ecosystem, so I think people would listen to each others arguments (e.g. for/against the trade-offs between technical debt and the long tail of support) with sympathy or at least an open mind.
Not that my opinion has any weight here, but I’m inclined to disagree with the premise - pretty strongly, in fact - so I don’t see such an implication, nor any problem.
The maintainers of Linux distros, or of Conda, might be active Python users; enthusiasts, even. Certainly those things are “publications of Python”. However, I absolutely would not consider them “maintained by the community” simply because the maintainers might be considered community members (or even taking it for granted that they all are).
First things first: Python is open-source. As such, nobody on the dev team, the steering committee, the mailing lists, etc. etc. can prevent any arbitrary SIG, organization, educational community, pet rat owners’ forum (perhaps they appreciate the irony of making snakes do their bidding), etc. from:
coming up with their own, idiosyncratic-but-shared understanding of “what constitutes ‘packaging’”, what the steps in the process are, what tools are necessary, etc.
producing their own metadata formats, hosting servers, protocols (maybe they don’t even care for the wheel format and it doesn’t bother them to break compatibility with pip), etc.
or for that matter: rewriting the standard library from scratch, designing and implementing new syntax features, orchestrating it all through their own custom alternative-to-PEP process, etc.
(As long, of course, as they adhere to the PSF License Agreement.)
What can be done by any group officially blessed by python dot org is to publish opinionated explanations of the goal of packaging and what the logical steps are; open protocols; PEPs to indicate future direction; etc. - and maintain their own servers.
If others don’t like the ideas contained therein, that’s fine - the consequence is that they aren’t guaranteed interoperability.
However, everyone who is responsible for any of those ideas, should be on the same page as everyone else responsible for other ideas in that category. As such, it makes sense to me that any new committees dedicated to some aspect of The Python Dot Org Officially Blessed Interpretation of What Python Is, should use the same governance process, yeah. And if others have their own interpretation of What Python Is, and the time and resources to work on that, then they can form their own committees for oversight, with their own rules.
In particular:
As I see it, Python Dot Org is certainly empowered to empower such a group, and such a group would certainly be able to act as councilors. Sometimes people don’t take the advice that’s freely given to them, and that’s fine. It’s fine if they want to advise themselves, too. It’s a completely separate concern and there’s neither cause, justification nor standing to try to impose, e.g., the PSF CoC, or voting procedures to admit new members, on them.
As such, I’m confused here, or perhaps I understand “governance process” differently. It doesn’t appear to me that e.g. Linux distro vendors would ordinarily have a member on this council, nor necessarily even as part of the packaging team. It’s also not clear to me why any work they do on Python (for example, to figure out which parts they want to put in /usr/lib and which parts in /usr/bin, and whether the result will work or not) requires any coordination (don’t they primarily just… build the software, move some files around and test whether the result works properly? And then set up their own tools to automate that? It’s not as if the Python team needs to have any input into how apt etc. work, yeah?)
What am I missing here? I feel like I must be far too naive to follow the discussion properly, because that part just isn’t making sense.
Maybe this is where I’m missing a step. Is there not, for example, a public list of PyPA members? How many people are we talking about here, anyway? How important is it for a Linux distro’s team to get someone into PyPA currently? Conversely, how important would I (my organization) have to be in order to care about something like that?
You have a reasonable point. In principle, the packaging council could look at conda and Linux distros as “out of scope” and perfectly entitled to do their own thing. But that’s basically the situation we have now, and we regularly get problems where pip doesn’t work smoothly with conda environments, or packaging tools conflict with Linux distribution layout conventions, or similar. People seem to want “the PyPA” (i.e., the proposed packaging council) to address these issues, but it’s not clear how we do that if the council’s remit doesn’t include defining interoperability rules that they will follow. In other words, having the distributions fall under the governance of the council matters to that extent at least.
The truth is, this is something of a case where the user community wants us to “fix everything”, and it’s a tricky judgement call to decide what constitutes “everything” (and hence, how much we’re willing to disappoint users who wanted more from us).
There’s a list of PyPA member projects. It’s the membership of the pypa github organisation. But as for individuals, anyone with maintainer status on any PyPA project is a member with voting rights (under the current rules). And the PyPA has no authority over who gets commit rights on individual projects. So by implication, the PyPA membership has no overall control over who is allowed to be a PyPA member. Which is, TBH, a bit weird…
Right now, not at all, as the PyPA’s powers are too limited for it to matter[1]. With the proposed council, the PyPA members will vote for the council, so being in the PyPA lets you have a say in who’s on the council. Whether that matters to you depends on how well the council does in reflecting community consensus, and what the council’s powers are. So still, maybe not much.
At the moment, it’s all pretty vague because we don’t have a concrete proposal. I’m hoping @smm can pull some order out of this and get something specific on the table for us to debate.
The PyPA doesn’t even have the power to approve PEPs. ↩︎
I think the question really is: who are we to make them follow those rules? How could we enforce that, even in principle?
Rather, I think the play is to make sure end users understand that, if the distro maintainers don’t follow the rules and something gets messed up, it’s their fault, not PyPC’s. My general impression is that Linux users are pretty good about receiving that kind of education No idea about conda, though.
Is it at least feasible to enumerate who those people are at any given time?
I more or less agree with this, but the big proviso for me is that those rules have to be good enough. Otherwise people will think “those rules don’t work, I’m going to ignore them” – and they may additionally think “that rule-making group isn’t making good rules, I’ll ignore everything they say”.
)
No idea about conda, though.