Hi all, While just looking at https://github.com/pytest-dev/pytest/blob/master/CONTRIBUTING.rst#submitting... I had some observations: 1. It says one of the objectives of having plugins under pytest-dev is "Sharing some of the maintenance responsibility (in case a maintainer no longer wishes to maintain a plugin)". I found this somewhat surprisingly worded. I thought it was more "protect the pytest community in case a maintainer goes AWOL". I think that's a significant difference, maintainers aren't supposed to think they can move the plugin there if they no longer feel like actively maintaining it. 2. The other thing this says is "We recommend that each plugin has at least three people who have the right to release to PyPI." I think that's somewhat light and does not ensure a package can be released if a maintainer does go AWOL. Could we change that to something like "each plugin must have at least three people from https://github.com/orgs/pytest-dev/teams/core/members who have the right to release to PyPI" [0]? Practically we should probably include a list of pypi usernames to that paragraph since there's not mapping otherwise. Any opinions on these? Cheers, Floris [0] Bonus points for whoever contributes a teams functionality to warehouse!
Floris, Let me pass on how other communities manage Github teams, repositories and shared maintenance. Here is the example from the Chef (config management tool) community: https://github.com/sous-chefs/terraform-github-org They have everything scripted with Terraform[1] in a public read only repo so everybody can see who the maintainers are for each repo. Ringo [1] https://www.terraform.io On Tue, Apr 17, 2018 at 10:33 PM, Floris Bruynooghe <flub@devork.be> wrote:
Hi all,
While just looking at https://github.com/pytest-dev/pytest/blob/master/ CONTRIBUTING.rst#submitting-plugins-to-pytest-dev I had some observations:
1. It says one of the objectives of having plugins under pytest-dev is "Sharing some of the maintenance responsibility (in case a maintainer no longer wishes to maintain a plugin)".
I found this somewhat surprisingly worded. I thought it was more "protect the pytest community in case a maintainer goes AWOL". I think that's a significant difference, maintainers aren't supposed to think they can move the plugin there if they no longer feel like actively maintaining it.
2. The other thing this says is "We recommend that each plugin has at least three people who have the right to release to PyPI." I think that's somewhat light and does not ensure a package can be released if a maintainer does go AWOL. Could we change that to something like "each plugin must have at least three people from https://github.com/orgs/pytest-dev/teams/core/members who have the right to release to PyPI" [0]? Practically we should probably include a list of pypi usernames to that paragraph since there's not mapping otherwise.
Any opinions on these?
Cheers, Floris
[0] Bonus points for whoever contributes a teams functionality to warehouse! _______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
-- *Ringo De Smet* ringo.de.smet@ontoforce.com
On Thu 19 Apr 2018 at 13:28 +0200, Ringo De Smet wrote:
Floris,
Let me pass on how other communities manage Github teams, repositories and shared maintenance. Here is the example from the Chef (config management tool) community:
https://github.com/sous-chefs/terraform-github-org
They have everything scripted with Terraform[1] in a public read only repo so everybody can see who the maintainers are for each repo.
That's a nice bit of automation.
Hi, Floris wrote:
That's a nice bit of automation.
I like the idea that it works somehow, but after looking at the README it is still undistinguishable from magic to me. Floris wrote:
[0] Bonus points for whoever contributes a teams functionality to warehouse!
This is why I think that this the definite way forward. Or ... if that won't happen just having a shared account sharing the secrets through keybase.io Cheers, Oliver
Floris, Oliver, If you want, I can get you bootstrapped on this Terraform setup. I can say I almost know Terraform inside out. ;-) Ringo On Thu, Apr 19, 2018 at 9:17 PM, Oliver Bestwalter <oliver@bestwalter.de> wrote:
Hi,
Floris wrote:
That's a nice bit of automation.
I like the idea that it works somehow, but after looking at the README it is still undistinguishable from magic to me.
Floris wrote:
[0] Bonus points for whoever contributes a teams functionality to warehouse!
This is why I think that this the definite way forward. Or ... if that won't happen just having a shared account sharing the secrets through keybase.io
Cheers, Oliver
-- *Ringo De Smet* ringo.de.smet@ontoforce.com
Thank you Ringo, I have no immediate plans to implement something like this but I would definitely appreciate some further docs/explanations/blog that unravels how it is accomplished. Cheers, Oliver On Fri 20. Apr 2018 at 08:26, Ringo De Smet <ringo.de.smet@ontoforce.com> wrote:
Floris, Oliver,
If you want, I can get you bootstrapped on this Terraform setup. I can say I almost know Terraform inside out. ;-)
Ringo
On Thu, Apr 19, 2018 at 9:17 PM, Oliver Bestwalter <oliver@bestwalter.de> wrote:
Hi,
Floris wrote:
That's a nice bit of automation.
I like the idea that it works somehow, but after looking at the README it is still undistinguishable from magic to me.
Floris wrote:
[0] Bonus points for whoever contributes a teams functionality to warehouse!
This is why I think that this the definite way forward. Or ... if that won't happen just having a shared account sharing the secrets through keybase.io
Cheers, Oliver
-- *Ringo De Smet* ringo.de.smet@ontoforce.com
Hi Ringo, On Fri 20 Apr 2018 at 08:26 +0200, Ringo De Smet wrote:
If you want, I can get you bootstrapped on this Terraform setup. I can say I almost know Terraform inside out. ;-)
Thanks for the offer to help with the project! One downside I see with doing this is that it's a fair amount of complexity which mostly only you will understand and be able to maintain. I'm not sure the current maintenance overhead of doing things by hand warrants taking such steps yet. But let's maybe check what the requirements would be before jumping to such conclusions, on top of my head: - have groups of users like pytest-dev-core pytest-plugin-authors etc - configure users/groups/repos on github - configure users/groups/repos on bitbucket - configure users/groups/projects on pypi - whatever else I forgot Would it be able to help with all of these? Cheers, Floris
Ringo
On Thu, Apr 19, 2018 at 9:17 PM, Oliver Bestwalter <oliver@bestwalter.de> wrote:
Hi,
Floris wrote:
That's a nice bit of automation.
I like the idea that it works somehow, but after looking at the README it is still undistinguishable from magic to me.
Floris wrote:
[0] Bonus points for whoever contributes a teams functionality to warehouse!
This is why I think that this the definite way forward. Or ... if that won't happen just having a shared account sharing the secrets through keybase.io
Cheers, Oliver
Floris, On Sat, Apr 21, 2018 at 10:50 AM, Floris Bruynooghe <flub@devork.be> wrote:
One downside I see with doing this is that it's a fair amount of complexity which mostly only you will understand and be able to maintain. I'm not sure the current maintenance overhead of doing things by hand warrants taking such steps yet. But let's maybe check what the requirements would be before jumping to such conclusions, on top of my head:
- have groups of users like pytest-dev-core pytest-plugin-authors etc - configure users/groups/repos on github - configure users/groups/repos on bitbucket - configure users/groups/projects on pypi - whatever else I forgot
Would it be able to help with all of these?
No, currently it would only help with setting up users/groups/repos on your Github organization. *Ringo De Smet* ringo.de.smet@ontoforce.com
participants (3)
-
Floris Bruynooghe -
Oliver Bestwalter -
Ringo De Smet