This seems like an odd stance to take. You're basically saying "Damn the torpedoes, full speed ahead." Or, put differently, "I don't care what the bug is, unless it's data corruption, we're not calling it a blocker." Technically, that means that I could merge a PR that removes configure.ac, and that would not be considered a blocker. This is especially true in light of what Josh said -- we can't even make distribution tarballs right now because there's a problem in ROMIO's configure (which has been known for weeks, but no one has fixed it yet). That is definitely a blocker, even though it is not a data corruption bug.
I think I would be amenable to an intention more along the lines of "let's closely evaluate bugs that come up and see if they really are blockers, because we really want to get v5.0.x out the door as soon as possible." ________________________________ From: devel <devel-boun...@lists.open-mpi.org> on behalf of Josh Hursey via devel <devel@lists.open-mpi.org> Sent: Tuesday, February 21, 2023 7:37 PM To: Open MPI Developers <devel@lists.open-mpi.org> Cc: Josh Hursey <jjhur...@open-mpi.org> Subject: Re: [OMPI devel] 5.0.x bug release blockers hard stop I think that's fine, with the exception of fixing the ROMIO packaging issue - which is a blocker (the release will not build without it fixed): - https://github.com/open-mpi/ompi/issues/11364 On Tue, Feb 21, 2023 at 4:58 PM Zhang, William via devel <devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org>> wrote: Hello everyone, During the weekly meeting today, I proposed that we stop labeling bugs as blockers for the 5.0.0 release which was seconded with the exception of data corruption bugs. In the interest of having 5.0.0 released, we must put a hard stop on diagnosing and ingesting bug fixes. We can have these be brought in during later bugfix releases. Due to the low attendance during the meeting today and lack of Jeff, Brian, 5.0.x release managers, I wanted to re-iterate on this through e-mail to get wider buy-in. Please levy any objections to this here. Thanks, William -- Josh Hursey IBM Spectrum MPI Developer
