Status of project?

[xd009642]

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)

[sergree]

Same question.

[bluss]

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]

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]

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]

Looking at PRs that could be for a patch release

• Add conversions from nalgebra types #554
• Pairwise summation #577 (I saw some perf stats on it, not sure if this is ready yet or more work needs doing)
• Implement PartialEq/Eq for SliceInfo #689

Yeah just looking at what PRs pass and are marked with breaking changes:

• Add support for inserting new axes while slicing #570
• Implement arithmetic ops on more combinations of types #744
• Stack and concatenate #844 looks like it needs work, but it is stack & concat

[ZuseZ4]

#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]

@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]

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:

• If it makes ergonomics easier at little cost (I think Implement PartialEq/Eq for SliceInfo #689 falls into that ballpark)
• If it adds features that are in numpy but not ndarray that's a good thing.
• It's came out of design discussion and there's a good motivation for it.

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]

@xd009642 small clarification regarding #844 . This change is not a breaking one so it can be released in 0.13.2.

[bluss]

@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]

@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]

@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]

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]

Sounds great. I will try to watch out for it, but also feel free to ping me here or on zulip.

[bluss]

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]

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]

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]

@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]

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]

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]

Yeah all sounds good to me 👍 I'll close this issue as the initial query is resolved 😄