Closed
Description
Just wondering what's happening with ndarray (and the future 0.14.0 release). It looks like there hasn't been much activity in recent months. Just curious btw (and willing to assist in any PRs if help is wanted)
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
sergree commentedon Oct 7, 2020
Same question.
bluss commentedon Oct 8, 2020
Hi - good question.
I haven't had all that much time lately, as is evident. We need a new plan for maintainership, since the current maintainers are busy or don't have time. I myself have enough time to answer questions, hand over and help with releases and release planning.
In my view we need something more than just merging PRs, which is prioritization and making releases. My view on maintainership is that there is no use in merging a PR without a plan for when and how it will be "shipped" - in a release.
I can answer and help on all issues that are general, about the data structure and library internals, but I don't have the time to look at numerical algorithms.
As discussion forum I would recommend using the issues here and alternatively looking into room #rust-sci:matrix.org on the matrix chat network (not very active).
xd009642 commentedon Oct 8, 2020
Well I'd be willing to help out, although I'd need some time to get familiar with things internally and what the current goals are. I'll take a look at the matrix room as well 👀
It might be a naive approach but I'd consider going through all the PRs that don't add any breaking changes just bug fixes and small features and making a 0.13.2, then seeing what's left and working out what would be wanted for 0.14.0.
bluss commentedon Oct 8, 2020
Sounds reasonable too - I expect there isn't much there. Updating deps, and landing something with stack and concatenate seems to be the most important (both breaking), so that could be the small goal for 0.14.
xd009642 commentedon Oct 8, 2020
Looking at PRs that could be for a patch release
Yeah just looking at what PRs pass and are marked with breaking changes:
ZuseZ4 commentedon Oct 8, 2020
#810 would also be a breaking change.
I'm note sure how much these bumps will improve performance wise, but since they should come basically for free, I guess they could be interesting.
bluss commentedon Oct 9, 2020
@xd009642 Merging a PR straight up because it passes is not exactly my philosophy, but if we should have some progress, we shouldn't just listen to me(!) :) We also need to think we have the right design and a plan to release it.
A few of the changes in current master are unfortunately unreleased - but if I'm not mistaken they are non-breaking and are nice minor improvements, like #814 and #809
xd009642 commentedon Oct 9, 2020
Oh yeah agreed just merging all the things isn't a good strategy, I just figured cutting down the list of PRs to ones to make a decision on would be useful and then hopefully merge or decline them 😄
As for design I generally hold the view that a feature is good if the design/performance are satisfactory and:
For the patch PRs I identified, PartialEq for slices looks useful to me -although it may need some work/answers regarding dyn? I'm not sure about #577 I don't understand what it's doing enough yet. As for #554 I'm less sure about that one, it goes up to nalgebra 0.16 and the latest version is 0.22. Instead I'd consider just updating the docs to point to https://github.com/rust-cv/nshare which has ndarray/nalgebra conversions in and doesn't put a maintenance burden on ndarray.
andrei-papou commentedon Oct 14, 2020
@xd009642 small clarification regarding #844 . This change is not a breaking one so it can be released in 0.13.2.
bluss commentedon Oct 24, 2020
@xd009642 So what's the action item in this issue, do you want to be a maintainer and help accepting PRs (with an eye for how it fits into being released soon)? 🙂
I'm clear with what I can do in comment #843 (comment) - from my view it means we don't merge numpy-like algorithms and numerics, unless there is someone else who can review it.
I have some time now, but I would like to either go right for 0.14.0 or 0.13.2 and then immediately 0.14. That is because to me it is clear that we can't wait with bumping deps, so it's useless to work on only non-breaking changes.
xd009642 commentedon Oct 24, 2020
@bluss I'm happy to be a maintainer and help if you'll have me 😄. And going straight to 0.14 is personally fine by me, keeping things simple by minimising the amount of work is always fine with me
ZuseZ4 commentedon Nov 7, 2020
@xd009642 Do you have any branch where you are working on merging the different PR?
I might be able to help by douple-checking your changes or helping with smaller fixes.
xd009642 commentedon Nov 7, 2020
Not yet, I was considering creating a branch where I roll up a few different PRs but I haven't had the time this week. I can try and do something over the weekend though 😄
ZuseZ4 commentedon Nov 7, 2020
Sounds great. I will try to watch out for it, but also feel free to ping me here or on zulip.
bluss commentedon Nov 7, 2020
Let's do the work on the PRs here in the repo I think, then we won't duplicate work I hope (does that make sense?)
xd009642 commentedon Nov 9, 2020
Hmm looking at the PR comments in more detail for the ones I highlights (barring stack and concat as it's merged), it looks like there's still unanswered questions in terms of performance or API for them. With this in mind I'm tempted to suggest no more features just docs cleanups etc and cut a new release. Then look to those PRs for the next release.
Also, for the nalgebra conversion feature instead could just update the docs to suggest https://github.com/rust-cv/nshare as an crate. I know the rust-cv community wg although small have been quick to update their small crates like that for users so it moves the maintenance burden away from ndarray 😁 .
If there's no disagreements I'll start work on a PR where I look at any areas docs/examples could be firmed up (if it's needed at all, it might all be good already) and bump version numbers for a release.
thecooldrop commentedon Nov 14, 2020
I would like to note that I would have interesst in contributing as well. I have been following this library for a long time, and I feel that Rust could be a great competitor to something like Numpy.
xd009642 commentedon Nov 19, 2020
@bluss @jturner314 I'm just gonna tag you both in 3 PRs I think should be merged before a release. And then I think a new release should be done to get stack/concat and other new features out into the world 😄
nilgoyette commentedon Nov 23, 2020
Even if this lib was to die at 0.13.1, we at least need to bump dependencies! But ndarray is needed by too much people and we can't let it rot :) In fact, this project is core to our commercial projects and I'll help if needed. I'm not at all a Rust expert, but I'll do what I can. Do not hesitate to tag me when you need it. I'll check the PR from time to time.
bluss commentedon Nov 28, 2020
We did it. See the release work (release note, deprecations, final commits) to see what I normally do for releases.
PR review is helpful if you want to contribute.
However in my view - we must never be without a plan to release (hypocritical from my speaking position). That means that once a feature has been merged, we need to think about how to bring it to the users as quickly as possible. That means that just merging PRs does not bring the project forward. 🙂
And the help this project needs to be sustainable is to have more people in release management roles - who think about quality and the whole picture.
I've been clear that I can mostly focus on data structure and basics - if you want to work on numerical algorithms etc, then we need your help. And there's still a lot of cleanup and refactoring to do, too.
Some items didn't make it into 0.14 despite being in the milestone: https://github.com/rust-ndarray/ndarray/milestone/1
so the milestone is renamed to 0.15.
There is a release planning issue here: #794
I would guess it's likely that we go quickly to 0.15. But there is time for merging non-breaking changes before then. The reason that non-breaking changes are so easy to handle is that release management is so simple with them.
xd009642 commentedon Nov 29, 2020
Yeah all sounds good to me 👍 I'll close this issue as the initial query is resolved 😄