Maintainability going forward: one possible, easy solution #260
Comments
|
@itamarst I'm definitely OK getting others to help with the maintenance. I don't have any plans for major changes, but I'm fine if folks wanted to continue to evolve things as well. Let me know what you're thinking and how you'd want to proceed. |
|
My personal goal is to get a release out 😁 After that my time here is up... unless there's other issues that affect However, one way you can make it easier for contributors with commit to make things happen is by automating the release process, so e.g. if you tag a release it gets deployed. And then anyone with commit access to repo can do release without having to give them all PyPI credentials. If that's something you're comfortable with I can submit a PR for that. And if you're happy getting more contributors, probably 30 minutes spent going through issue/closed PR backlog and messaging people who you're comfortable with would get you a person or three you add as a collaborator with commit access in GitHub. |
|
@itamarst Fair enough! I released 0.12.7. If you did have a PR to perform a release from a tag I would certainly be grateful. I'll also do an audit of the PRs and issues to see if there is anyone who would like to help contribute. Thanks for the suggestions and your help! |
|
Just curious if there have been any updates on the release process/timing? I know everyone is busy :) I've been trying to use my fork / a git repo source but, because of the way my code is packaged/distributed, I really need to get back to a release from PyPI... I can certainly look into alternatives for myself but was hoping a new release would be coming soon?! Thanks for your work on this! |
|
There have been some releases with some fixes, separate from this issue. Is there a specific fix you want to get from git that isn't released? |
|
There's an outstanding PR for first part of automation, and then when that's in I will do PR for the rest of release automation. But it's up to ionrock to merge, and he doesn't have a lot of time, so... I'm sure it'll happen eventually. In short term, you can have pip install off of this git repo instead of your fork? |
|
Fair enough. I'll take another look at the workarounds. I've got a bit of a unique situation at the moment where I'm using this as a dependency for something that is both 1) also a pypi package, and 2) being added to a private zip which is delivered to customers. I've got it as Thanks for getting back to me — let me know if a release sneaks its way out 😉 |
|
The other alternative is vendoring, I guess. |
|
See #300 |
Since you have very little time to maintain this, like we all do, one thing I've successfully done, inspired by https://lukasa.co.uk/2016/04/One_Of_The_Team/ via Hynek Schlawack: anyone who lands a PR gets asked if they want commit access.
In particular, same company that is getting me to fix the memory usage bug in
pipneeded some bug fixes in sparkmagic, which had huge pile-up of PRs and basically zero maintainers. So I finagled commit access, merged some, and then recruited those people to be maintainers, since I didn't actually know anything about Spark :) Basically just "hey do you want to be maintainer, you just need to agree to code of conduct, and try to PRs with reviews instead of pushing directly." You can enforce the latter in repo settings I think?The result was pretty successful; it hasn't gotten a huge development push, but it is being actively maintained by people who are not me (https://github.com/jupyter-incubator/sparkmagic/commits/master?before=ac0852cbe88a41faa368cf1e1c89045a2de973bf+35&branch=master).
And maybe in this case you want to be a little more careful, given the potential for supply chain attack on
pip, but you already have a bunch of commits/PRs from people who are credible and apparently motivated to contribute.The text was updated successfully, but these errors were encountered: