Open newville opened 9 months ago
@lebigot for consistency, and for all the same reasons as transferring this repo to an organization is a good idea, and as a test of the process, I transferred newville/asteval to lmfit/asteval today. It was very smoothly, took a few minutes, and all issues and pull requests migrated (there was no wiki or discussions to test). So, I think transferring should be safe.
I had been using GH Pages as the docs, and that (newille.github.io/asteval) failed to transfer, but this is uncertainties
is using a different place for the docs. I'm working on that now ;)
FWIW, I then forked lmfit/asteval back to newville/asteval.
FWIW, I then forked lmfit/asteval back to newville/asteval.
According to transfer documentation linked above, you could rename your fork something other than asteval
and then github would redirect newville/asteval to lmfit/asteval. I don't know if you care about that. At the moment github.com/newville/asteval is one of the top search results for asteval at the moment.
@wshanks thanks - actually, GitHub did a very good job of automatically redirecting and updating links.
It did less well with the mapping of "gh-pages" from the personal repo to the new organization. But that was easy enough to copy (done first) and then turn into a redirect once the docs were installed for https://lmfit.github.io/asteval. No complaints from me. Anyway, that's not relevant for this repo so I am reasonably sure that it should go smoothly.
I did a semi-automated download of the HTML for all the issues and pull requests for lebigot/uncertainties
. These could go into a wiki (or other) if they get lost in the transfer.
Thank you for helping with the transfer.
I did transfer the repository to lmfit/uncertainties
: I like the clarity that it brings as to whom is currently in charge of the package.
Here are some things that you may want to update:
__author__
in the __init__.py
should be updated.I don't think I have access to the roles settings for the lmfit/uncertainties
project, so I'll let @newville take care of this.
Since keeping a trace of the origin of the project is important to me, I added a very short History section at the bottom of the README (with a hidden ReST note indicating that I would like this origin to remain in the README).
For PyPI, can you send me a PyPI user name so that I can make you an owner? Thanks!
I was convinced by arguments for supporting Python 3.8+.
Let me know if/when you need anything else for the transfer. Thanks again for picking up this project!!
@lebigot Thanks -- that looks great. It looks like the issues and pull requests transferred too.
We'll work on tidying up the authors, readme, etc.
Maybe we all (including @wshanks @andrewgsavage @jagerber48) can start to use a discussion (over the next few days?) at lmfit/uncertainties on plans for 1 month, 3 months, and 6 months.
FWIW, my PyPI user name is "newville". Hope that another one gets added too.
Thanks!
Thanks. I added you as an owner on PyPI for uncertainties.
@wshanks @andrewgsavage @jagerber48: I'd be happy to make you owners too. Just give me a PyPI username (you can send it to eric.lebigot@normalesup.org).
My PyPI username is wsha
.
While I am posting, I will make one more pitch about forks and transferred repositories because I think what I was saying before might not have been understood. When the repository is transferred, the issues and pull requests are preserved, and links within the issues and pull requests are rewritten with the new location, so for example what linked to https://github.com/lebigot/uncertainties/issues/180
(I have to use code formatting to prevent GitHub from rewriting it as the new address) now links to https://github.com/lmfit/uncertainties/issues/180. It may have seemed like I was referring to this rewriting as "redirecting" in my previous messages, but what I actually mean by redirecting is that the GitHub server will continue to dynamically redirect requests for the old repository location to the new one. So for cases outside of github.com like search engine results or local git clones from before the transfer, the old address will still get to the correct data as long as @lebigot does not name his fork of uncertainties as uncertainties
. For example, while https://github.com/lebigot/uncertainties/issues/180
currently redirects to #180, https://github.com/newville/asteval/issues/68
(random issue from my browsing history) now gives a 404 page instead of redirecting to https://github.com/lmfit/asteval/issues/68 because that issue does not exist on the new fork of asteval.
my pypi username is andrewgsavage
@wshanks Ah, I get your point better now - thanks for the clarification!
Thanks @wshanks and @andrewgsavage: I invited you to become owners of the PyPI uncertainties project.
@wshanks: I had understood what you mentioned, so you were clear enough, thanks. 😀 If I have to fork lmfit/uncertainties
, I'll create a new lebigot/uncertainties-fork
repository so as to preserve the GitHub redirections.
My PyPi user name is jagerber48
@jagerber48: you should have received an invite!
@wshanks: I sent a new invite, as the previous one expired.
In the future, @newville, @wshanks, @andrewgsavage, feel free to ping me with @lebigot! I won't be following everything, so please do this when you think I can help. Thanks!
Thanks, @lebigot. I didn't realize they expired quickly. I will accept soon.
@lebigot You have called for a maintainer and offered to help with the transition to a new maintainer.
I have multiple projects that depend on this package and would like to make sure this project is maintained. By age alone, I might be closer to retirement than you ;), but I might be willing to fork this to the
lmfit
Github organization (which can have multiple projects and members), and maintain this package from there. I would add you as a member of that if you are willing.If that is acceptable to you, we could then figure out to push to PyPI, and conda-based "feedstocks" and packages.