mpir
mpir copied to clipboard
wbhart
Time for a PR + new release?
The last release is 147 commits behind master and is over 18 months old. The releases are here while current updates seem to be done (only by @BrianGladman ?) at https://github.com/BrianGladman/mpir.
No one has volunteered to do the work for a release. Volunteers are welcome.
We also decided to separate Windows releases (which Brian manages) from releases for other platforms, to cut down on the work the person who is doing the release has to manage.
In the meanwhile there are 161 commits https://github.com/wbhart/mpir/compare/mpir-3.0.0...wbhart:mpir:master and some important parts like integration of the mpf_cmp_z() function are only in master since 2018 (@BrianGladman's repo doesn't provide tags so there isn't any kind of "release" there either).
No one has volunteered to do the work for a release. Volunteers are welcome.
Given the last code change in this repo being from December 2020 (and there weren't much, those were from 2018) I'd say current master seems quite stable (= extensive testing done).
I therefore suggest to pull in the single outstanding PR (from 2022) that fixes a case where MPIR could not be built at all [I see no possible regressions], then just set the version number, Changelog and tag and call it a release.
The only thing that volunteers can do here is to suggest exactly that and, if you really like that, have the Changelog and the version number updated as a PR (pulling those and tagging needs write access to the repo).
Some years ago I came in out of nowhere, and merged @BrianGladman's branch back into master. It was a somewhat complex set of changes requiring several passes and a lot of review. Unsurprisingly, I didn't have the trust or buy-in to persuade @BrianGladman or @wbhart to risk wasting their time with me to review/merge my pull request. Unfortunately, what happened instead was that I inflamed a bit of conflict and catalyzed the "official" split of the repo into Windows (visual studio) and non-Windows. I wanted to say I'm sorry for that - it's something that I still often look back upon as a major personal failure. You guys have some serious credentials and math chops that are likely far above what I might accomplish in my career, tho I hope to one day achieve as much as you have. I have a lot of respect for what you've done here, and I feel bad that my only contribution may have been a step towards the end of the mpir.
Here is my best estimate of the situation (please correct me because I'm just guessing/going from memory) - Brian never really bought into the git workflow, and it's more of a waste of his energy when all he really needs at this point is a safe place to put his changes. If people find his work useful, great. Otherwise, they can leave it. As far as he's concerned, the non-Windows side shouldn't affect him. Symmetrically, William doesn't really care what builds in Windows. You guys have had long careers and I can see why you wouldn't want to spend any more time on menial tasks like merging/playing nice with code you'll never use, maintaining a website and changelog, tagging and testing releases and dealing with all the people that come out of the woodwork asking for help, new features, reporting bugs (that are often not bugs), etc etc.
It's maybe also worth mentioning other big contributers are no longer with us in this world for many years, so it's mostly just Brian and William left doing the majority of updates (afaik). I think it's been established they won't be doing another release themselves.
So going forward (and I'm thinking long term - like say the next 10-20 years) I see a few possibilities:
- @BrianGladman and @wbhart continue their separate repos and the rest of the world migrates to different libraries with official releases. Eventually the commits stop and mpir goes away (the path we're on today).
- Someone or a small group forks mpir and maintains releases under a new name (presumably periodically merging in @wbhart and @BrianGladman's repos)
- Someone or a small group is given commit access to the mpir github repo, and eventually ownership access, and potentially the old mpir.org domain, and they (potentially) kick the can a bit further down the road.
Some questions for @wbhart and @BrianGladman:
- a) Do you still own rights to the mpir.org domain? It appears to still be registered to the same owner since 2007...
- a1) Side note: did you know GitHub now does free hosting of static pages? I believe you can even assign it an outside domain name (i.e. mpir.org)
- a2) Was there a mailing list or discussion page on the old website, or is that all in GitHub today? I'm remembering some old conversations we had but I'm not able to find them.
- b) Which of the above would be your preferred path? (If you see a different one, let me know)
Personally, I've moved to Linux 100% of the time, so GMP is easier to grab (and I rarely play with this stuff lately). I'm no longer familiar with the differences between GMP and mpir besides the Windows build. The issue I see with option 2 is Brian and William aren't likely to merge and stay in sync with a new repo, so over time merges would become more painful. Option 3 embodies the same issue I had when I failed to reconcile the differences between Brian's and William's repos. It would be nice to have one consistent history and repo and carry on the torch.
I think a while back I might've even talked a bit about this with @GitMensch, COBOL rings a bell. Anyhow, hi again! Cheers all!
On 11/10/2024 21:16, Kevin Hake wrote:
Some years ago I came in out of nowhere, and merged @BrianGladman https://github.com/BrianGladman's branch back into master. It was a somewhat complex set of changes requiring several passes and a lot of review. Unsurprisingly, I didn't have the trust or buy-in to persuade @BrianGladman https://github.com/BrianGladman or @wbhart https://github.com/wbhart to risk wasting their time with me to review/merge my pull request. Unfortunately, what happened instead was that I inflamed a bit of conflict and catalyzed the "official" split of the repo into Windows (visual studio) and non-Windows.
Hi Kevin
In practice I think the split was really the result a realisation that support for MPIR on Linux/GCC would not be possible once Bill Hart moved first onto work on FLINT and then left this field of work completely.
MPIR on Windows has always relied on the C/C++ work being done by the Linux/GCC team, my major contribution being the development and integration of fast windows based assembler code to ensure its ongoing competitive performance on Windows as new CPU architectures emerge.
I am no longer doing this so MPIR on Windows will slowly die from old age (although it is mature and stable enough to last a long time!).
I wanted to say I'm sorry for that - it's something that I still often look back upon as a major personal failure. You guys have some serious credentials and math chops that are likely far above what I might accomplish in my career, tho I hope to one day achieve as much as you have. I have a lot of respect for what you've done here, and I feel bad that my only contribution may have been a step towards the end of the mpir.
No need to apologise since, in my view, the primary reasons for the split lie elsewhere.
Here is my best estimate of the situation (please correct me because I'm just guessing/going from memory) - Brian never really bought into the git workflow, and it's more of a waste of his energy when all he really needs at this point is a safe place to put his changes. If people find his work useful, great. Otherwise, they can leave it. As far as he's concerned, the non-Windows side shouldn't affect him.
Correct. All I worried about (with minor exceptions) was one directory (and its subdirectories) that contained the high performance assembler code for Windows and another that ran the Visual Studio build code.
[snip]
It's maybe also worth mentioning other big contributers are no longer with us in this world for many years, so it's mostly just Brian and William left doing the majority of updates (afaik). I think it's been established they won't be doing another release themselves.
Bill Hart has left this field of work completely so the main MPIR repository is now dormant. I don't foresee doing any more work on mine either.
So going forward (and I'm thinking long term - like say the next 10-20 years) I see a few possibilities:
- @BrianGladman https://github.com/BrianGladman and @wbhart https://github.com/wbhart continue their separate repos and the rest of the world migrates to different libraries with official releases. Eventually the commits stop and mpir goes away (the path we're on today).
Agreed that this is what I assume will now happen.
[snip]
Some questions for @wbhart https://github.com/wbhart and @BrianGladman https://github.com/BrianGladman: a) Do you still own rights to the mpir.org domain? It /appears/ to still be registered to the same owner since 2007... a1) Side note: did you know GitHub now does free hosting of static pages? I believe you can even assign it an outside domain name (i.e. mpir.org) a2) Was there a mailing list or discussion page on the old website, or is that all in GitHub today? I'm remembering some old conversations we had but I'm not able to find them. b) Which of the above would be your preferred path? (If you see a different one, let me know)
Bill Hart will have to answer this.
[snip]
with my regards
Brian Gladman
I've not much to add to what Brian said. His assessment is accurate. I am nearly 50 and still don't have a permanent job, so I left computer algebra to work in AI (specifically theorem proving). There will be no more work from me on MPIR.
To answer your questions:
a) No I don't own the domain any more. Not for a long time. a1) Yes I am aware. a2) No, this list was all there was. b) Path to what?
I would suggest if there is still interest in MPIR (though I don't know why there would be, there has been no new assembler work for many years), that someone else fork the project and maintain it. I absolutely do not have time to work on it in any way.
Bill.
On Fri, 11 Oct 2024 at 23:03, Brian Gladman @.***> wrote:
On 11/10/2024 21:16, Kevin Hake wrote:
Some years ago I came in out of nowhere, and merged @BrianGladman < https://github.com/BrianGladman>'s branch back into master. It was a somewhat complex set of changes requiring several passes and a lot of review. Unsurprisingly, I didn't have the trust or buy-in to persuade @BrianGladman https://github.com/BrianGladman or @wbhart < https://github.com/wbhart> to risk wasting their time with me to review/merge my pull request. Unfortunately, what happened instead was that I inflamed a bit of conflict and catalyzed the "official" split of the repo into Windows (visual studio) and non-Windows.
Hi Kevin
In practice I think the split was really the result a realisation that support for MPIR on Linux/GCC would not be possible once Bill Hart moved first onto work on FLINT and then left this field of work completely.
MPIR on Windows has always relied on the C/C++ work being done by the Linux/GCC team, my major contribution being the development and integration of fast windows based assembler code to ensure its ongoing competitive performance on Windows as new CPU architectures emerge.
I am no longer doing this so MPIR on Windows will slowly die from old age (although it is mature and stable enough to last a long time!).
I wanted to say I'm sorry for that - it's something that I still often look back upon as a major personal failure. You guys have some serious credentials and math chops that are likely far above what I might accomplish in my career, tho I hope to one day achieve as much as you have. I have a lot of respect for what you've done here, and I feel bad that my only contribution may have been a step towards the end of the mpir.
No need to apologise since, in my view, the primary reasons for the split lie elsewhere.
Here is my best estimate of the situation (please correct me because I'm just guessing/going from memory) - Brian never really bought into the git workflow, and it's more of a waste of his energy when all he really needs at this point is a safe place to put his changes. If people find his work useful, great. Otherwise, they can leave it. As far as he's concerned, the non-Windows side shouldn't affect him.
Correct. All I worried about (with minor exceptions) was one directory (and its subdirectories) that contained the high performance assembler code for Windows and another that ran the Visual Studio build code.
[snip]
It's maybe also worth mentioning other big contributers are no longer with us in this world for many years, so it's mostly just Brian and William left doing the majority of updates (afaik). I think it's been established they won't be doing another release themselves.
Bill Hart has left this field of work completely so the main MPIR repository is now dormant. I don't foresee doing any more work on mine either.
So going forward (and I'm thinking long term - like say the next 10-20 years) I see a few possibilities:
- @BrianGladman https://github.com/BrianGladman and @wbhart < https://github.com/wbhart> continue their separate repos and the rest of the world migrates to different libraries with official releases. Eventually the commits stop and mpir goes away (the path we're on today).
Agreed that this is what I assume will now happen.
[snip]
Some questions for @wbhart https://github.com/wbhart and @BrianGladman https://github.com/BrianGladman: a) Do you still own rights to the mpir.org domain? It /appears/ to still be registered to the same owner since 2007... a1) Side note: did you know GitHub now does free hosting of static pages? I believe you can even assign it an outside domain name (i.e. mpir.org) a2) Was there a mailing list or discussion page on the old website, or is that all in GitHub today? I'm remembering some old conversations we had but I'm not able to find them. b) Which of the above would be your preferred path? (If you see a different one, let me know)
Bill Hart will have to answer this.
[snip]
with my regards
Brian Gladman
— Reply to this email directly, view it on GitHub https://github.com/wbhart/mpir/issues/272#issuecomment-2408176391, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3HJTIP3WAHME34NCCI3LZ3BDMBAVCNFSM6AAAAABPYTB3F2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGE3TMMZZGE . You are receiving this because you were mentioned.Message ID: @.***>
Thanks for clarifying! I feel a bit better now that I understand the situation more. @wbhart by path I meant one of the 3 possibilities I listed - I think you both clarified that # 1 was the intended direction (the one you both already settled on long ago).
For @GitMensch - do you think it's worth putting together a "final release", given development is likely finished? If so, @wbhart would you be comfortable giving shared ownership to the repo to him? Or would you be more comfortable if he just branched his own repository and used that instead?
Yes, I think a "final" release would be good. I can help with the steps I've outlined above (but would not like to do this in a fork).
After the release is done I'd suggest to adjust the README and mark the repo as archived, and yes, I offer helping with that as well.
I really don't have time to do anything here. Please fork the repo. It's a single button to press on GitHub. Then you can do whatever you want with it.
Note I am not available to help with the release.
Bill.
On Sat, 12 Oct 2024 at 16:15, Simon Sobisch @.***> wrote:
Yes, I think a "final" release would be good. I can help with the steps I've outlined above (but would not like to do this in a fork).
After the release is done I'd suggest to adjust the README and mark the repo as archived, and yes, I offer helping with that as well.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
A release in a fork is not the same as an official one...
Note I am not available to help with the release.
The only thing you'd need to do is to go to https://github.com/wbhart/mpir/settings/access + provdide login + click on "add", then add people to the Maintainer list - then those can do releases and tags and accepting PRs.
I suggest you start a community project and fork the repo there. I will not be allowing releases that I had nothing to do with to happen on my personal repository.
You can always point people back to this discussion if you have trouble convincing anyone that it is "official". So long as you don't use my name to promote your efforts, it is as official as it can possibly be, as MPIR is otherwise a dead project. I have no intention of reviving it myself to compete.
I do not have the time to produce another release of MPIR, and so if you want to convince the community at large that a release you worked on should be counted as official, then I'm sorry, but I don't have the time to do the work required to add my approval. You will have to manage without me being involved.
Good luck.
Bill.
On Sun, 13 Oct 2024 at 03:29, Simon Sobisch @.***> wrote:
A release in a fork is not the same as an official one...
Note I am not available to help with the release.
The only thing you'd need to do is to go to https://github.com/wbhart/mpir/settings/access + provdide login + click on "add", then add people to the Maintainer list - then those can do releases and tags and accepting PRs.
— Reply to this email directly, view it on GitHub https://github.com/wbhart/mpir/issues/272#issuecomment-2408790343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3HJR2RYCJXJO42P2G52LZ3HLIJAVCNFSM6AAAAABPYTB3F2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYG44TAMZUGM . You are receiving this because you were mentioned.Message ID: @.***>