python-memcached
python-memcached copied to clipboard
linsomniac
Discussion: Moving to a new maintainer.
For a variety of reasons that are ultimately unimportant, I have not been able to find any attention for maintaining this package. I've recently had an offer from Morgan Fainberg to take over maintenance of the package. That proposal includes importing it into the OpenStack CI infrastructure for testing and development. That would remove it from Github, as I understand it, and use the review.openstack.org gerrit instance, and releasing it on pypi.
If anyone has an opinion on this, please comment here.
As an additional point, there would still be a git replica in github but it would be under the OpenStack organization (https://github.com/openstack/python-memcached or similar). The changes would be:
- review.openstack.org would be used for submitting new patches/code review/CI testing
- bug tracking would need to be handled in launchpad until openstack's new bug tracker would be spun up and eventually bug tracking would happen in this (soon to be setup) bug tracker.
From a standpoint of what we're looking to do with this module if it is taken over:
- Continue maintenance on it, ensure we handle the outstanding bugs, etc
- improve module, as needed
- Maintain the current interface for interacting with memcached, as the module has a lot of drive time on it and uses in the wild.
- This would not make python-memcached "part of openstack", just a consumer of the CI infrastructure (e.g no CLA or other agreement needed to contribute, etc). There is a little more overhead in contributing due to the need to setup a user account in gerrit, but this is (imho) worth it for the benefit the CI infrastructure brings to us.
- License, etc will (of course) be maintained as it is today.
Reasons for why I have offered to take this over are simple. Pylibmc is very good, but is based in c-bindings, which means we have extra work in openstack due to the way we use eventlet and greenlet. The other options are bmemcached and pymemcached. Both of the alternatives are much more complex to use. I also know that some distributions have issues with convergence of "client" libraries in their main repositories, so keeping the options to a single case in "main" is important.
I am happy to answer/discuss any questions or concerns here before taking this over. Thanks for the open discussion!
Hi Sean. I very much appreciate your openness to switching maintainer. We get busy and our attention may go away, it's important to recognize it so that projects can move ahead for those who care. I can assure you that you'll be happy of the work being done within OpenStack, and also the git review workflow is super nice.
FWIW, I work with @morganfainberg very closely and am also volunteering my time to maintaining the project and addressing some of the open issues/PRs.
I'm going to call this discussion closed. I'll take a look and see if there's anything else I can move into the base repo, and then I'm going to ask Morgan to start the process of migrating it. We had a discussion at PyCon about the process.
I'll start the process of getting the bits in place for moving this to the openstack infrastructure.
I'll propose a PR here once that is ready to link to the new authoratative locations and redirect back to LaunchPad for bugs.
A couple things I'll need:
- granted "owner" on PyPi of the project, my username there is "mdrnstm" - you don't need to drop your permissions, just add mine and I'll do the rest.
- given admin to the LP project, i'm also "mdrnstm" on launchpad
I expect I'll have the import bits pushed to a forked copy in the next day or so, and it imported to openstack-infra by the end of the week provided we have no hiccups.
A new release of python-memcached will not be pushed from the openstack infra immediately, so we might want to push with the current fixes added over the last week before the import.
I also want to say thanks @linsomniac for maintaining this library as long as you have! :) I'm happy we can continue it!
Revisiting this conversation. I know it dropped off the radar (some emails I think were lost - and I got a bit swamped, now revisiting directly).
Sean, are you willing to continue with this transition?
What advantage does moving testing, issues, etc. to OpenStack provide? Are there problems with the current setup on GitHub? Speaking personally, nearly all the Python libraries (mainly Django related) use GitHub so it's a familiar interface. I don't think I've contributed to anything that uses OpenStack.
One option is moving to the Jazzband organization. I would like to help maintain things in at least the short term to solve issues/regressions that affect Django.
@morganfainberg @linsomniac Have you been able to come to a conclusion about this? I see there are people willing to contribute (including me), but without a maintainer there's a lot of issues and PR that are left unattended.
I agree with @timgraham that @JazzBand would be an option. However, I am not sure if we need two synchronous clients going forward. https://github.com/pinterest/pymemcache is backed by a major corporation, and I am always happy, when companies pay their developers to do open source code.
Truth is, since Pintrest is already spending money on maintaining pymemcache, I'd rather spend my free time on other projects.
This is an officially recommended client for Django and it would be great to have it back to an active development stage (e.g with jazzband / @timgraham ).
Relevant discussions for using pinterest/pymemcache with Django :
- https://groups.google.com/forum/#!topic/django-developers/PAiLQybcGT8
- https://code.djangoproject.com/ticket/29887
- https://github.com/django-pymemcache/django-pymemcache
@linsomniac Just raising the issue of maintainership here again. Would you be prepared to move this project to the Jazzband organisation as recommended by a number of others above?
