On 8/2/19 5:18 PM, Steven A. Falco wrote:
On 8/2/19 3:05 PM, Wayne Stambaugh wrote:
Looks like we will be forgoing a 5.1.3 release and jumping to 5.1.4.
This bug is a definite show stopper. We need to do a better job of
testing fixes before we merge them into the 5.1 branch. Maybe we
need
to start doing release candidates on the stable branch before
releasing
buggy bug fixes? For those packagers who are providing 5.1.3 for
distos, I would avoid releasing it.
I'm attempting to stop 5.1.3 from moving into Fedora. I may need a
Fedora admin to grant me additional privileges to do so, since the
build has already entered the package queue.
I'll wait for 5.1.4 to be tagged and then I'll start up a new build.
As to Wayne having to delay his announcement because of insufficient
Fedora karma, I'll request that people on this list test and give
karma for future builds. Just three positive votes will be sufficient
to expedite release.
As to the discussion from
https://bugs.launchpad.net/kicad/+bug/1838448 I've now had two folks
working for RedHat advise me not to circumvent the
_GLIBCXX_ASSERTIONS, because of security concerns related to buffer
overflows. So I think in the interest of safety, I need to leave
those asserts in place.
Steve
I think I found a solution. I can tag commit
090073cc3b79f4f646f3c82390eb02a253e488d8 as 5.1.4. No translations are
required so we should be able to tag the translations, libs, and docs
at
the same commit as the 5.1.3 tag. This would only require updating the
builds and stable release announcement. Unfortunately this doesn't
solve the assertion issue on Fedora. If I include the commits that fix
the Fedora issue, we will have to wait for the translations because
there are a bunch of string changes after commit
cf949609b25a43b66b985baab8ae5354ad8510ae so including them would push
back the release significantly. If there are no objections, I will tag
5.1.4 today so we can get moving on a new stable release.
Cheers,
Wayne
