search

plone / pylons-project-assimilation

for the Pylons Project community to become a part of the Plone Foundation
0 stars 0 forks source link

Grant Owner access on PyPI releases to Plone Foundation #13

Open stevepiercy opened 5 years ago

stevepiercy commented 5 years ago

Grant Owner access on PyPI releases to Plone Foundation.

Depends on #4.

gforcada commented 5 years ago

@stevepiercy we have a plone user on pypi that is managed by @plone/release-team, maybe that's enough?

digitalresistor commented 5 years ago

@gforcada that @plone/release-team is not a public group, is there a list of people that are involved in that? What are the policies around pushing new releases? How does one become a member of that team?

gforcada commented 5 years ago

Oh, I see that github groups are only public within an organization... :confused:

The current members are @esteele , @mauritsvanrees , @tisto and me.

Policies on pushing new releases... that's a good topic, we are aiming to make releases often, as in cut a new release from the stable branches (4.3.x and 5.1.x right now, with a pending final 5.0.x) and try to please the eager developers for alpha/beta releases of bleeding edge (i.e. 5.2 currently).

We have a mailing list to coordinate, but as we lots of small packages (~100) and some of them are more or less interdependent (CMFPlone and p.a.upgrade for example) it is not as easy as clicking a button or pushing a tag and be done with it :sweat_smile: we would love to reach that point, but so far we are not there.

Becoming member of that team would be as simple as asking for it. Basically the release manager (@esteele ) is the one steering the wheel, while the others are trying to help on the way (i.e. releasing the unproblematic packages now and then), again, we are aiming to be able to full releases on our own, but so far we have a bus factor of 1.

As this is about assimilating pylons projects, how are you dealing with releases? :thinking: I guess that it would be a really good to share your and ours experience and see if we can help each other on making things as easy as possible.

As for tooling, we are heavy users of zest.releaser (we have our set of plugins collected in plone.releaser) and that together with jenkins and our github<->jenkins integration (mr.roboto written on pyramid :wink: )

I guess though, that even if organizations are merged you would keep on making your own releases, or you would also like us to take over? Would you consider joining our release team efforts? :smile:

digitalresistor commented 5 years ago

@gforcada at the moment I am asking questions to figure out how this is going to work and find out where there are sharp and pointies that we need to be aware of :-).

I would expect us to continue doing our own releases, as we have been. We tend to have various projects where we are in complete maintenance mode and I'll pick up PR's and push releases. Other ones we manage more closely/follow best practices/testing.

We don't have any automated deployments or pushes to PyPI. We also tend to do a lot more manual steps but it works for us.

I wouldn't be opposed to joining forces as necessary, but I may be a little protective of the projects I am actively the maintainer/largest contributor for and want to make sure that as we are actively moving towards this assimilation that we have an idea of how this is going to work!

digitalresistor commented 5 years ago

We also tend to use Travis/Appveyor for testing.

stevepiercy commented 5 years ago

The matter of how we manage GitHub write access has its own issue #8. Each project under the GitHub Pylons organization has its own way of doing things. We don't have a bus-factor-of-one situation on GitHub.

This issue covers the problem where projects under the Pylons Project have too many bus-factor-of-one for their PyPI release managers. That definitely needs to improve. I would like to grant access to a responsible party so that we don't have to hunt down a PyPI project Owner when a new release is needed.

It sounds like the plone PyPI user may address this issue, but we'd need to know how that works, who has access, and how Plone safeguards that access. @gforcada where can we get more information on that?

gforcada commented 5 years ago

@stevepiercy the plone pypi user is managed by the @plone/release-team members (so @esteele , @mauritsvanrees , @tisto and me).

Regarding safeguarding, the password, if you meant that is stored safely by each of us in our laptops. Which kind of other information would you need?

stevepiercy commented 5 years ago

@gforcada yes, how to protect access to make a release is part of it.

My greater concern is how we protect against human error. Say for example a user contacts the Plone release team, claiming that the release manager for Pylons/ProjectX has not made a release of merged PRs for some time and appears to have abandoned ProjectX. How does the release team determine whether they should cut a release to PyPI, instead of leaving it up to the PyPI Owner of ProjectX?

Under the Pylons Project, PyPI access has always been controlled by the Owner role for that project on PyPI. The Owner sets their own release process, and may grant access to Maintainers. By bringing in the Plone Release Team to resolve our bus-factor-of-one problem, we need to determine and document when it is OK for them to cut a release. I hope that clarifies my question.