Plan for 0.2.21

[xianyi]

We will release a hotfix (0.2.21) version this week.

@martin-frbg

[martin-frbg]

OK with me, and I would not want to have anything else besides the reversal of my misguided patch (which already happened a week ago) in 0.2.21

[brada4]

Or vice versa with corrected change?

[martin-frbg]

I do not want to take any chances with that, given that the cgroups functionality has been missing for at least as long as cgroups are available. As far as I know, the person who requested it has not even tried it yet, and that PR was not intended for 0.2.20 anyway as far as I am concerned.
If anything, the cpuid_x86 fix for proper L1 size detection would be a worthier candidate - but I do not want this hotfix release to be delayed like 0.2.20 was, given that some people are waiting for the Android softfp code and others for all the other fixes since 0.2.19, or just for updated windows binaries.

[brada4]

Agree

[boegel]

Are there any details available about what warrants a quick bugfix release after 0.2.20? And are things still on track to release 0.2.21 this week?

[martin-frbg]

The sole reason is #1252 - a defective PR by me(implementing the "cgroups" feature mentioned above) that unexpectedly got merged into 0.2.20 instead of the post-release develop branch. This broke the build on all systems that use something other than glibc for their system library.

[boegel]

Thanks for clarifying @martin-frbg!

Does that mean that 0.2.20 and 0.2.21 will effectively be equivalent on systems that do use glibc?

[brada4]

Yes

[martin-frbg]

Not quite, as 0.2.21 will have the problematic change removed (on the grounds that I did not even expect it to be in 0.2.20, and it has not received serious testing to make sure the intended functionality is actually there on systems big enough for it to make sense). If you want to try a version that supposedly uses only the subset of cpus alloted to it by a cpuset command, either stay with 0.2.20 if you have glibc systems only, or better yet take the current develop snapshot that has other improvements (e.g. utilizes the full 32k L1 cache on Haswell and later Intel chips vs. a misdetected 8k)
If you have no need for cgroup/cpuset functionality then yes 0.2.20 and 0.2.21 will be equivalent on glibc

[boegel]

@martin-frbg Thanks for the clarification!

Being aware of cpusets is quite important to us, but only if it works as intended of course...

@xianyi Do you have a specific date for the 0.2.21 release? Is something in particular blocking it (and can we help)?

[brada4]

You can still couple cpusets with OPENBLAS_NUM_THREADS, it is not a killer feature per se

[boegel]

@xianyi Sorry to keep pushing for this, but we're kind of blocked by the missing OpenBLAS 0.2.21 release...

[pbregener]

I don't want to sound too harsh, but I don't think that the handling of this issue helps improving the reputation of this project. The critical bug was discovered (and fixed!) hours after the release, and a new version was promised to be released within a few days. Now weeks months have passed and nothing has happened.

[thecaligarmo]

I was wondering if there was an update on this? I noticed there is the release-0.2.21 branch (https://github.com/xianyi/OpenBLAS/tree/release-0.2.21) but it seems to not been advanced into master. Is there something blocking the change and if not, do we have an expected time frame for when it will get merged in?

[brada4]

Currently that branch is equal to 0.2.20. But a good sign release is proceeding.

[martin-frbg]

The last I know is that xianyi wanted to cherry-pick unspecified commits from develop, which I did not think would be a good idea for a "hotfix release". Beware that at the moment it looks as if the release-0.2.21 branch is identical to the "broken" 0.2.20 release, i.e. it does not even have the bad PR reverted (which master already has).

[brada4]

#1089 after #1262 looks quite a cherry....

[martin-frbg]

Don't want to go there after the experience with #1252 - if this is meant to be a quick fix (for some value of "quick") at all. Rather hope the release cycle will be picking up speed again sometime. There are several other goodies waiting, such as the current rewrite of the cmake files, but again a "hotfix release" is not the time and place for them IMHO.

[thecaligarmo]

So from the sounds of it, a "hotfix" for 0.2.20 would just be to install 0.2.20 and then to patch it up with the following commit: 88a35ff
Does that seem to be an acceptable thing at this moment?

If a release with the fix isn't coming then is there an expected time for a future release? Such as 0.3.0? Or is that way to far in the pipeline atm? Thanks again =)

[martin-frbg]

1. Yes, which happens to be what the current "master" branch is.
2. xianyi created Plan for 0.3.0 #1245 a month ago, suggesting a release date of "about Dec 2017"

[thecaligarmo]

Ah ok. So the current master branch is up to date, but it just hasn't been released yet through an official release? Thanks for all this =)

[EricQLi]

Thanks for your contribution. I hope compiled files for windows x64 of the present version will be released.

[boegel]

@xianyi Any updates on releasing 0.2.21, or whatever the next OpenBLAS release may be?

[jakirkham]

Any news on this?

[martin-frbg]

Have not had a reply from xianyi to a message I sent ten days ago, but given how much time has passed my inclination is to go directly to 0.3.0. I believe @ViralBShah also tried to contact him two weeks or so ago given the important performance fixes for the Mac platform that arose from #1470.

[jakirkham]

Would it be reasonable to migrate OpenBLAS development to an org? Has xianyi voiced any reservations about this? Seems like the people most involved in the code have shifted over the years and the people doing the most work don't seem to have the permissions necessary to progress.

[martin-frbg]

No idea of the pros and cons of such a move. As far as I know, xianyi's business is still related to, and maybe still builds on, OpenBLAS. Two weeks is not long enough to declare him missing, especially so
relatively shortly after the Chinese New Year.

[ViralBShah]

I have certainly not heard back from @xianyi to my email. I agree it may be worth waiting a bit longer. In any case, the project has become much bigger and would benefit from an organization with shared ownership while continuing to acknowledge @xianyi 's leadership.

[simonbyrne]

Also, xianyi seems to already control the OpenBLAS org: https://github.com/OpenBLAS, so if we want that name we would need his help in any case.

[martin-frbg]

I do not plan a coup just yet :) and it is possible that I already have the necessary powers (though not the experience) to prepare a release myself if need be.

[jakirkham]

To be clear, was not proposing a coup. xianyi has done a great job running this project.

That said, it does seem like xianyi's time is in high demand. So was wondering if sharing the leadership role might help OpenBLAS to progress. If the thought amongst those involved in maintaining the project is this is not necessary to make progress, great.

However the fact is this issue has been open for half a year despite being a request for a hotfix. The last release is approaching a year old and in some cases won't work without patching anyways. We know of a few critical bugs that are fixed in development since the last release. It would be nice to have them in a proper release to capitalize on these.

Please let us know if there is some way to help move this forward.

[smatzek]

I've seen some activity on other issues about the 0.3.0 release. Is that release going to be tagged on OpenBLAS in this location, and if so, what is the timeframe?

[martin-frbg]

xianyi created a 0.3.0 release branch four weeks ago. Unfortunately at around the same time, a potential issue with the ARM7 vfp support popped up. By the time this was determined to be unrelated to OpenBLAS, contact with xianyi was lost again (although he still seems to be updating his company-related pages on github)

[ViralBShah]

It would be great if other maintainers could tag the release. I think several projects are waiting on this.

[martin-frbg]

0.3.0 is out now, as mentioned in #1245.