[Audacity-devel] P2 bugs and Freeze Delay

I still have some work I have been doing on 437. But its much more than I
thought it was going to be!

Sorry if I have contributed to any delay! :(

Mark

Post by James Crook
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could block
on. We also currently have issues that do not get recorded as bugs,
such as the patchy organisation of our patches to 3rd party libraries,
and (current) failure to build on Mac. Bug 437
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2, is a
blocker for release because it is reported on as a limitation/issue with
Audacity on the Wikipedia page. The patches to 3rd party libraries have
ballooned with work to work around wx3 issues in this release, so it is
important that we sort that out.
The work on patches is important. If we don't do it, we're not helping
wxWidgets to improve the library we depend on. We need our own clone of
wxWidgets to be fully patched with all our patches. We need to document
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and communicate
them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than set
a specific date. We have to have made enough progress for it to happen.
--James (with RM hat on).
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-10-11 11:56:58 UTC

Post by Mark Young
I still have some work I have been doing on 437. But its much more than I
thought it was going to be!
Sorry if I have contributed to any delay! :(

No Mark, you've not in the least contributed to the delay. The delay is
mostly down to 'technical debt' and we took a very big dose of technical
debt when wxWidgets moved to 3.0 - because wx3 has many things about it
that we have to work around.

I would have liked to have stayed with wx2.8.12 until wxWidgets 3.x had
fewer problems, but we had to move 'up' because Linux distros were
building Audacity with wx3, even though we were not ready for it and
still on wx2. We've also for 2.1.3 had to move up on compiler version,
which is not altogether a bad thing, but it was unexpected that we would
have to.

--James.

Post by Mark Young
Mark

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2016-10-11 15:05:24 UTC

James made a fork of wxWidgets at their GitHub. I have pushed a branch
called audacity-fixes containing exactly what I added onto version 3.0.2
source. One of these is a cherry-pick from 3.1.0, with a bit of
adaptation, to get the pinch and spread gestures. The others fix things.

https://github.com/audacity/wxWidgets/tree/audacity-fixes

I will replicate the commit comments in the wiki.

What else is my priority?

PRL

Post by Mark Young
I still have some work I have been doing on 437. But its much more than I
thought it was going to be!
Sorry if I have contributed to any delay! :(
No Mark, you've not in the least contributed to the delay. The delay is
mostly down to 'technical debt' and we took a very big dose of technical
debt when wxWidgets moved to 3.0 - because wx3 has many things about it
that we have to work around.
I would have liked to have stayed with wx2.8.12 until wxWidgets 3.x had
fewer problems, but we had to move 'up' because Linux distros were building
Audacity with wx3, even though we were not ready for it and still on wx2.
We've also for 2.1.3 had to move up on compiler version, which is not
altogether a bad thing, but it was unexpected that we would have to.
--James.
Mark
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could block
on. We also currently have issues that do not get recorded as bugs,
such as the patchy organisation of our patches to 3rd party libraries,
and (current) failure to build on Mac. Bug 437http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2, is a
blocker for release because it is reported on as a limitation/issue with
Audacity on the Wikipedia page. The patches to 3rd party libraries have
ballooned with work to work around wx3 issues in this release, so it is
important that we sort that out.
The work on patches is important. If we don't do it, we're not helping
wxWidgets to improve the library we depend on. We need our own clone of
wxWidgets to be fully patched with all our patches. We need to document
the problems we've worked around:http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and communicate
them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than set
a specific date. We have to have made enough progress for it to happen.
--James (with RM hat on).
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-10-11 15:28:45 UTC

Paul, please also add to wiki any wx3 workarounds you made that did not
have to have wx3 patches, but that we still want to communicate upstream
to wxWidgets.

Your priority, I think, is Linux and Mac P2 issues, (other than great
big wormcans like accessibility for Mac).

So, I'm thinking:

Bug 1450 - Mac: Text grid cells cannot be TAB'bed out of
http://bugzilla.audacityteam.org/show_bug.cgi?id=1450

Bug 1446 - (Mac and Linux) Audacity does not launch if TempDir is on a
FAT/exFAT file system
http://bugzilla.audacityteam.org/show_bug.cgi?id=1446

The Linux ASSERT bugs worry me. I'm not up to speed on why ASSERT is
reporting in release builds. Is it a mistake of ours in building on
Linux, or something else? If wx3 is defaulting to ASSERTs reporting in
release, that seems strange, and/but I'd think we'd want to avoid those
ASSERTs by avoiding the conditions from our code that leads to them,
rather than just switching the reporting off. So I'd like an
update/opinion on what is going on.

--James.

Post by Paul Licameli
James made a fork of wxWidgets at their GitHub. I have pushed a branch
called audacity-fixes containing exactly what I added onto version 3.0.2
source. One of these is a cherry-pick from 3.1.0, with a bit of
adaptation, to get the pinch and spread gestures. The others fix things.
https://github.com/audacity/wxWidgets/tree/audacity-fixes
I will replicate the commit comments in the wiki.
What else is my priority?
PRL

Paul Licameli

2016-10-11 16:24:23 UTC

http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets

Now updated with detailed explanations of each of the patches.

PRL

Post by James Crook
Paul, please also add to wiki any wx3 workarounds you made that did not
have to have wx3 patches, but that we still want to communicate upstream
to wxWidgets.
Your priority, I think, is Linux and Mac P2 issues, (other than great
big wormcans like accessibility for Mac).
Bug 1450 - Mac: Text grid cells cannot be TAB'bed out of
http://bugzilla.audacityteam.org/show_bug.cgi?id=1450
Bug 1446 - (Mac and Linux) Audacity does not launch if TempDir is on a
FAT/exFAT file system
http://bugzilla.audacityteam.org/show_bug.cgi?id=1446
The Linux ASSERT bugs worry me. I'm not up to speed on why ASSERT is
reporting in release builds. Is it a mistake of ours in building on
Linux, or something else? If wx3 is defaulting to ASSERTs reporting in
release, that seems strange, and/but I'd think we'd want to avoid those
ASSERTs by avoiding the conditions from our code that leads to them,
rather than just switching the reporting off. So I'd like an
update/opinion on what is going on.
--James.

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2016-10-12 14:17:57 UTC

Am I wrong. or weren't ASSERT'S always allowed on Linux in release
configuration builds? My understanding is just that we have a whole
heap more asserts than we used to, due to changing to wx3.

Gale

Gale Andrews

2016-10-12 14:39:02 UTC

Leaving aside Wikipedia, the reported frequency of user impact of
that problem is quite low. When this happens during recording
it could (weakly) be argued as user error, because of the already
existing Status Bar messages for remaining disk space.

So I think in practice bug 437 is like bug 276 PulseAudio freeze.
437 would get moved to P1 at a time when we have the resources
to fix it and the time to test the fix thoroughly so that new bugs are
not introduced.

If we are waiting for certification of the Win/Mac installers then it makes
sense to continue clearing P2's that RM thinks could block the release.
Are we now making progress on certification?

Note also that the release is technically blocked anyway. it does not
build on Mac because of how the gcc 4.9 requirement has been
specified. I suggest fixing that or people on Mac can't test new fixes.

Gale

Post by James Crook
The patches to 3rd party libraries have
ballooned with work to work around wx3 issues in this release, so it is
important that we sort that out.
The work on patches is important. If we don't do it, we're not helping
wxWidgets to improve the library we depend on. We need our own clone of
wxWidgets to be fully patched with all our patches. We need to document
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and communicate
them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than set
a specific date. We have to have made enough progress for it to happen.
--James (with RM hat on).
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-10-12 21:28:06 UTC

Gale is right that the release is technically blocked anyway because of
Mac not building.

Any P2 can block release, and we have 36; I am also behind on getting
signing sorted; I'll be able to pay closer attention to Audacity in a
week's time, but it isn't wise to go into freeze at this juncture. I've
also got many things I need to catch up with that I have left to one
side to move Audacity forward, and I need to urgently clear those before
we freeze.

--James.

Leaving aside Wikipedia, the reported frequency of user impact of
that problem is quite low. When this happens during recording
it could (weakly) be argued as user error, because of the already
existing Status Bar messages for remaining disk space.
So I think in practice bug 437 is like bug 276 PulseAudio freeze.
437 would get moved to P1 at a time when we have the resources
to fix it and the time to test the fix thoroughly so that new bugs are
not introduced.
If we are waiting for certification of the Win/Mac installers then it makes
sense to continue clearing P2's that RM thinks could block the release.
Are we now making progress on certification?
Note also that the release is technically blocked anyway. it does not
build on Mac because of how the gcc 4.9 requirement has been
specified. I suggest fixing that or people on Mac can't test new fixes.
Gale

Peter Sampson

2016-10-13 10:20:08 UTC

In this freze delay, is there any chance that someone can spare a few
moments to address the issues in the P2 bug
http://bugzilla.audacityteam.org/show_bug.cgi?id=1427
and its associated Wording page in the Wiki
http://wiki.audacityteam.org/wiki/Wording

A couple of these wre logged as long ago as 2008, eight years ago and
have lain untouched since then.

The changes would seem to be relatively simple to do and should only take
a few moments for someone with the right skills and priveleges.

The only one we may want to leave for post-2.1.3 if the modernization of
"program" to "application" - and note btw that this is a task that we are
part
way though so we have mixed nomenclature in this respect.

Cheers,
Peter

Post by James Crook
Gale is right that the release is technically blocked anyway because of
Mac not building.
Any P2 can block release, and we have 36; I am also behind on getting
signing sorted; I'll be able to pay closer attention to Audacity in a
week's time, but it isn't wise to go into freeze at this juncture. I've
also got many things I need to catch up with that I have left to one
side to move Audacity forward, and I need to urgently clear those before
we freeze.
--James.

makes

Post by Gale Andrews
sense to continue clearing P2's that RM thinks could block the release.
Are we now making progress on certification?
Note also that the release is technically blocked anyway. it does not
build on Mac because of how the gcc 4.9 requirement has been
specified. I suggest fixing that or people on Mac can't test new fixes.
Gale

communicate

Post by James Crook
them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than set
a specific date. We have to have made enough progress for it to happen.
--James (with RM hat on).
------------------------------------------------------------

------------------

Post by James Crook
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------

------------------

Post by Gale Andrews
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2016-10-13 15:30:56 UTC

The Scrubbing tooltip wordings are already fixed.

I don't think the LAME one matters and could be removed
from the page. It isn't creating confusion. The other two
might cause confusion.

For most people who encounter "Error Importing", Raw Data
import probably won't help. So it likely isn't worth an enh issue
on Bugzilla to have a button in "Error Importing" to open the
Import Raw dialogue.

Gale

On 13 October 2016 at 11:20, Peter Sampson

Post by Peter Sampson
In this freze delay, is there any chance that someone can spare a few
moments to address the issues in the P2 bug
http://bugzilla.audacityteam.org/show_bug.cgi?id=1427
and its associated Wording page in the Wiki
http://wiki.audacityteam.org/wiki/Wording
A couple of these wre logged as long ago as 2008, eight years ago and
have lain untouched since then.
The changes would seem to be relatively simple to do and should only take
a few moments for someone with the right skills and priveleges.
The only one we may want to leave for post-2.1.3 if the modernization of
"program" to "application" - and note btw that this is a task that we are
part
way though so we have mixed nomenclature in this respect.
Cheers,
Peter

Leaving aside Wikipedia, the reported frequency of user impact of
that problem is quite low. When this happens during recording
it could (weakly) be argued as user error, because of the already
existing Status Bar messages for remaining disk space.
So I think in practice bug 437 is like bug 276 PulseAudio freeze.
437 would get moved to P1 at a time when we have the resources
to fix it and the time to test the fix thoroughly so that new bugs are
not introduced.
If we are waiting for certification of the Win/Mac installers then it makes
sense to continue clearing P2's that RM thinks could block the release.
Are we now making progress on certification?
Note also that the release is technically blocked anyway. it does not
build on Mac because of how the gcc 4.9 requirement has been
specified. I suggest fixing that or people on Mac can't test new fixes.
Gale

Peter Sampson

2016-10-14 09:36:17 UTC

Post by Gale Andrews
I don't think the LAME one matters and could be removed
from the page. It isn't creating confusion.

If the advice message is as stated with LAME uncapitalized as "Lame"
as written in the entry for this on the Wording page - thean at the very
least we should capitalize it to "LAME" for consistency with the rest of
the application (and with the Manual and Wiki where we capitalize it).

Post by Gale Andrews
For most people who encounter "Error Importing", Raw Data
import probably won't help.

That's as maybe - but the issue that I have with the current message is that
it encloses the "Import Raw" in quoatation marks implying that it is an
Audacity entity or menu item and as such is misleading.

And as you, Gale, wrote a while back:
"Second option is clearly more user-friendly but either is an improvement "

Re the Software Playthrough message, this is simply a clarity of purpose
issue,
something that we always strive to achieve throughout the Manual abd we
shoud
strive to do likewise in the application too.

All three of these are so trival to effect that we have already spent more
time
discussing these than we have been involved in just getting on and doing it.

Thanks,
Peter.

Post by Gale Andrews
The Scrubbing tooltip wordings are already fixed.
I don't think the LAME one matters and could be removed
from the page. It isn't creating confusion. The other two
might cause confusion.
For most people who encounter "Error Importing", Raw Data
import probably won't help. So it likely isn't worth an enh issue
on Bugzilla to have a button in "Error Importing" to open the
Import Raw dialogue.
Gale
On 13 October 2016 at 11:20, Peter Sampson

Post by James Crook
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could

block

Post by James Crook
on. We also currently have issues that do not get recorded as bugs,
such as the patchy organisation of our patches to 3rd party

libraries,

Post by James Crook
and (current) failure to build on Mac. Bug 437
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2,

is a

Post by James Crook
blocker for release because it is reported on as a limitation/issue with
Audacity on the Wikipedia page.

release.

Post by Gale Andrews
Are we now making progress on certification?
Note also that the release is technically blocked anyway. it does not
build on Mac because of how the gcc 4.9 requirement has been
specified. I suggest fixing that or people on Mac can't test new

fixes.

Post by Gale Andrews
Gale

Post by James Crook
The patches to 3rd party libraries have
ballooned with work to work around wx3 issues in this release, so it

Post by James Crook
important that we sort that out.
The work on patches is important. If we don't do it, we're not

helping

Post by James Crook
wxWidgets to improve the library we depend on. We need our own clone of
wxWidgets to be fully patched with all our patches. We need to document
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and communicate
them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than

set

Post by James Crook
a specific date. We have to have made enough progress for it to happen.
--James (with RM hat on).
------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

Post by Peter Sampson
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2016-10-14 14:20:34 UTC

OK I'll deal with this presently in order to clear that "Wording" page out.

Gale

On 14 October 2016 at 10:36, Peter Sampson

Post by Gale Andrews
I don't think the LAME one matters and could be removed
from the page. It isn't creating confusion.

Post by Gale Andrews
For most people who encounter "Error Importing", Raw Data
import probably won't help.

That's as maybe - but the issue that I have with the current message is that
it encloses the "Import Raw" in quoatation marks implying that it is an
Audacity entity or menu item and as such is misleading.
"Second option is clearly more user-friendly but either is an improvement "
Re the Software Playthrough message, this is simply a clarity of purpose
issue,
something that we always strive to achieve throughout the Manual abd we
shoud
strive to do likewise in the application too.
All three of these are so trival to effect that we have already spent more
time
discussing these than we have been involved in just getting on and doing it.
Thanks,
Peter.

Post by James Crook
Gale is right that the release is technically blocked anyway because of
Mac not building.
Any P2 can block release, and we have 36; I am also behind on getting
signing sorted; I'll be able to pay closer attention to Audacity in a
week's time, but it isn't wise to go into freeze at this juncture.
I've
also got many things I need to catch up with that I have left to one
side to move Audacity forward, and I need to urgently clear those before
we freeze.
--James.

Leaving aside Wikipedia, the reported frequency of user impact of
that problem is quite low. When this happens during recording
it could (weakly) be argued as user error, because of the already
existing Status Bar messages for remaining disk space.
So I think in practice bug 437 is like bug 276 PulseAudio freeze.
437 would get moved to P1 at a time when we have the resources
to fix it and the time to test the fix thoroughly so that new bugs are
not introduced.
If we are waiting for certification of the Win/Mac installers then it makes
sense to continue clearing P2's that RM thinks could block the release.
Are we now making progress on certification?
Note also that the release is technically blocked anyway. it does not
build on Mac because of how the gcc 4.9 requirement has been
specified. I suggest fixing that or people on Mac can't test new fixes.
Gale

Post by James Crook
The patches to 3rd party libraries have
ballooned with work to work around wx3 issues in this release, so it is
important that we sort that out.
The work on patches is important. If we don't do it, we're not helping
wxWidgets to improve the library we depend on. We need our own
clone
of
wxWidgets to be fully patched with all our patches. We need to document
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and communicate
them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than set
a specific date. We have to have made enough progress for it to happen.
--James (with RM hat on).
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-11-03 12:32:00 UTC

We're still in freeze delay, with 36 P2 bugs.
I now have a Mac Mini and can build and sign dmgs. Also I have a cert
so that I can sign Windows installers. These are both requirements for
release now.

I am not comfortable as RM proceeding to release with 36 P2 bugs. On the
other hand I do not want to delay freeze indefinitely!
Given we're still where we were on these 36 bugs, but do now have the
certs for signing, I'm getting ready for us to move forward again, and
accept that I/we will have way more P2s than we would like for 2.1.3.

http://bugzilla.audacityteam.org/show_bug.cgi?id=1427 - Wording Issues,
needs to be DEVEl-FIXMADE before we freeze.
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 - Write fails
without warning when disk full.

http://bugzilla.audacityteam.org/show_bug.cgi?id=1499 - Linux: ASSERT on
check dependencies, is an apparently solved representative of the Linux
ASSERT bugs, which include 1232 and 1412 and possibly 1509.

I'd like
a) Gale to check the status of these Linux ASSERT bugs.
b) A recommendation from linux builders as to what updated wording we
should put in the linux build instructions in README.txt.
I think the current instructions are inadequate, given that it is/was
easy to compile with a release version of wxWidgets that nevertheless
has ASSERTs in it.

With these dealt with, I'd be happier about moving forward into freeze.
We would at least be down from the 36 open P2s.

--James

Post by James Crook
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could
block on. We also currently have issues that do not get recorded as
bugs, such as the patchy organisation of our patches to 3rd party
libraries, and (current) failure to build on Mac. Bug 437
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2, is a
blocker for release because it is reported on as a limitation/issue
with Audacity on the Wikipedia page. The patches to 3rd party
libraries have ballooned with work to work around wx3 issues in this
release, so it is important that we sort that out.
The work on patches is important. If we don't do it, we're not
helping wxWidgets to improve the library we depend on. We need our
own clone of wxWidgets to be fully patched with all our patches. We
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and
communicate them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than
set a specific date. We have to have made enough progress for it to
happen.
--James (with RM hat on).

Cliff Scott

2016-11-03 12:52:10 UTC

Then regressions will be included in the release? I'm thinking of bugs like 1450 that will be immediately noticed by existing users.

Cliff

Post by James Crook
We're still in freeze delay, with 36 P2 bugs.
I now have a Mac Mini and can build and sign dmgs. Also I have a cert
so that I can sign Windows installers. These are both requirements for
release now.
I am not comfortable as RM proceeding to release with 36 P2 bugs. On the
other hand I do not want to delay freeze indefinitely!
Given we're still where we were on these 36 bugs, but do now have the
certs for signing, I'm getting ready for us to move forward again, and
accept that I/we will have way more P2s than we would like for 2.1.3.
http://bugzilla.audacityteam.org/show_bug.cgi?id=1427 - Wording Issues,
needs to be DEVEl-FIXMADE before we freeze.
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 - Write fails
without warning when disk full.
http://bugzilla.audacityteam.org/show_bug.cgi?id=1499 - Linux: ASSERT on
check dependencies, is an apparently solved representative of the Linux
ASSERT bugs, which include 1232 and 1412 and possibly 1509.
I'd like
a) Gale to check the status of these Linux ASSERT bugs.
b) A recommendation from linux builders as to what updated wording we
should put in the linux build instructions in README.txt.
I think the current instructions are inadequate, given that it is/was
easy to compile with a release version of wxWidgets that nevertheless
has ASSERTs in it.
With these dealt with, I'd be happier about moving forward into freeze.
We would at least be down from the 36 open P2s.
--James

Post by James Crook
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could
block on. We also currently have issues that do not get recorded as
bugs, such as the patchy organisation of our patches to 3rd party
libraries, and (current) failure to build on Mac. Bug 437
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2, is a
blocker for release because it is reported on as a limitation/issue
with Audacity on the Wikipedia page. The patches to 3rd party
libraries have ballooned with work to work around wx3 issues in this
release, so it is important that we sort that out.
The work on patches is important. If we don't do it, we're not
helping wxWidgets to improve the library we depend on. We need our
own clone of wxWidgets to be fully patched with all our patches. We
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and
communicate them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than
set a specific date. We have to have made enough progress for it to
happen.
--James (with RM hat on).

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-11-03 13:35:40 UTC

Post by Cliff Scott
Then regressions will be included in the release? I'm thinking of bugs like 1450 that will be immediately noticed by existing users.
Cliff

Cliff, that's partly why I am asking/discussing.
I think 1450 and 1446 are unacceptable - but so is an indefinite delay.

1427 (wording) is a P2, but a must fix in my view, as agreed wording is
easy to fix and fixing it before translation is just the right thing to do.
437 (write fails silently) is a personal must-fix. It is just silly
having it as a long standing black mark against us on the Audacity
Wikipedia page.
1499 (Linux ASSERTs) appear to be a family of related issues, and we
seem to have a fix, but the loop hasn't quite been closed yet.
These (147, 437, 1499) are my must fix P2s.

So yes, I'm currently prepared to go to freeze with 1450 and 1446 still
present. Lobbying to me, as you are doing, may change my position to
include those two, 1450 and 1446, in my must-fix list, or might
encourage Gale to raise them both to P1. Regressions usually are P1,
though in this case Gale has made an exception that these two
regressions are sufficiently mild to be OK as P2.

At the moment though we do not have developer energy for any of the P2s,
so I will probably only hold up the freeze for the smaller list, as the
alternative of an indefinite delay in release is not OK.

--James.

Post by Cliff Scott

Post by James Crook
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could
block on. We also currently have issues that do not get recorded as
bugs, such as the patchy organisation of our patches to 3rd party
libraries, and (current) failure to build on Mac. Bug 437
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2, is a
blocker for release because it is reported on as a limitation/issue
with Audacity on the Wikipedia page. The patches to 3rd party
libraries have ballooned with work to work around wx3 issues in this
release, so it is important that we sort that out.
The work on patches is important. If we don't do it, we're not
helping wxWidgets to improve the library we depend on. We need our
own clone of wxWidgets to be fully patched with all our patches. We
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and
communicate them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than
set a specific date. We have to have made enough progress for it to
happen.
--James (with RM hat on).

Cliff Scott

2016-11-03 15:32:03 UTC

James,

Understand. Thanks for the explanation. Wish I could code, but that's beyond me, at least for now.

Cliff

Post by Cliff Scott
Then regressions will be included in the release? I'm thinking of bugs like 1450 that will be immediately noticed by existing users.
Cliff

Cliff, that's partly why I am asking/discussing.
I think 1450 and 1446 are unacceptable - but so is an indefinite delay.
1427 (wording) is a P2, but a must fix in my view, as agreed wording is
easy to fix and fixing it before translation is just the right thing to do.
437 (write fails silently) is a personal must-fix. It is just silly
having it as a long standing black mark against us on the Audacity
Wikipedia page.
1499 (Linux ASSERTs) appear to be a family of related issues, and we
seem to have a fix, but the loop hasn't quite been closed yet.
These (147, 437, 1499) are my must fix P2s.
So yes, I'm currently prepared to go to freeze with 1450 and 1446 still
present. Lobbying to me, as you are doing, may change my position to
include those two, 1450 and 1446, in my must-fix list, or might
encourage Gale to raise them both to P1. Regressions usually are P1,
though in this case Gale has made an exception that these two
regressions are sufficiently mild to be OK as P2.
At the moment though we do not have developer energy for any of the P2s,
so I will probably only hold up the freeze for the smaller list, as the
alternative of an indefinite delay in release is not OK.
--James.

Post by Cliff Scott

Post by James Crook
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could
block on. We also currently have issues that do not get recorded as
bugs, such as the patchy organisation of our patches to 3rd party
libraries, and (current) failure to build on Mac. Bug 437
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2, is a
blocker for release because it is reported on as a limitation/issue
with Audacity on the Wikipedia page. The patches to 3rd party
libraries have ballooned with work to work around wx3 issues in this
release, so it is important that we sort that out.
The work on patches is important. If we don't do it, we're not
helping wxWidgets to improve the library we depend on. We need our
own clone of wxWidgets to be fully patched with all our patches. We
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and
communicate them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than
set a specific date. We have to have made enough progress for it to
happen.
--James (with RM hat on).

Steve the Fiddle

2016-11-03 13:22:11 UTC

Asserts now occur quite infrequently on my machine. The one that I see
most frequently is
http://bugzilla.audacityteam.org/show_bug.cgi?id=1401 though the given
steps to reproduce do not appear to be relevant. It looks to me like a
race condition. I can go a week without seeing it, then suddenly it
will start appearing 5 times out of 10 until I reboot. I've suggested
a "works for me" fix for 1401 on bugzilla,

Steve

Post by James Crook
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could
block on. We also currently have issues that do not get recorded as
bugs, such as the patchy organisation of our patches to 3rd party
libraries, and (current) failure to build on Mac. Bug 437
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2, is a
blocker for release because it is reported on as a limitation/issue
with Audacity on the Wikipedia page. The patches to 3rd party
libraries have ballooned with work to work around wx3 issues in this
release, so it is important that we sort that out.
The work on patches is important. If we don't do it, we're not
helping wxWidgets to improve the library we depend on. We need our
own clone of wxWidgets to be fully patched with all our patches. We
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and
communicate them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than
set a specific date. We have to have made enough progress for it to
happen.
--James (with RM hat on).

Steve the Fiddle

2016-11-03 13:46:57 UTC

Some of the P2 ratings seem rather high to me, with nearly 50 P2s
logged this year, yet only 6 P5 bugs logged in the same period. Have
we perhaps inadvertently raised the bar?

Steve

Post by Steve the Fiddle
Asserts now occur quite infrequently on my machine. The one that I see
most frequently is
http://bugzilla.audacityteam.org/show_bug.cgi?id=1401 though the given
steps to reproduce do not appear to be relevant. It looks to me like a
race condition. I can go a week without seeing it, then suddenly it
will start appearing 5 times out of 10 until I reboot. I've suggested
a "works for me" fix for 1401 on bugzilla,
Steve

Post by James Crook
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could
block on. We also currently have issues that do not get recorded as
bugs, such as the patchy organisation of our patches to 3rd party
libraries, and (current) failure to build on Mac. Bug 437
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2, is a
blocker for release because it is reported on as a limitation/issue
with Audacity on the Wikipedia page. The patches to 3rd party
libraries have ballooned with work to work around wx3 issues in this
release, so it is important that we sort that out.
The work on patches is important. If we don't do it, we're not
helping wxWidgets to improve the library we depend on. We need our
own clone of wxWidgets to be fully patched with all our patches. We
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and
communicate them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than
set a specific date. We have to have made enough progress for it to
happen.
--James (with RM hat on).

James Crook

2016-11-03 15:09:27 UTC

I think we have raised the bar a bit - and that is actually correct that
we should. I.e. I think the bug ratings in Bugzilla now match the
criteria we have for what is P1, what is P2, what is P3 better than they
used to. We are also, I think, better at finding and slower at fixing
OSX bugs than we used to be. We are finding more OSX because you and
Peter have Macs now, and we are fixing fewer because we used to depend
heavily on Leland fixing them.

I don't want to use these as arguments for lowering the ratings, but am
happy enough to use these arguments, and the need to get a release out,
to justify releasing with 'too many' P2s.

--James.

Post by Steve the Fiddle
Some of the P2 ratings seem rather high to me, with nearly 50 P2s
logged this year, yet only 6 P5 bugs logged in the same period. Have
we perhaps inadvertently raised the bar?
Steve

Post by James Crook
Original plan was to go into Freeze on 9th October.
However, we have many serious P2 bugs (36), any of which RM could
block on. We also currently have issues that do not get recorded as
bugs, such as the patchy organisation of our patches to 3rd party
libraries, and (current) failure to build on Mac. Bug 437
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 which is P2, is a
blocker for release because it is reported on as a limitation/issue
with Audacity on the Wikipedia page. The patches to 3rd party
libraries have ballooned with work to work around wx3 issues in this
release, so it is important that we sort that out.
The work on patches is important. If we don't do it, we're not
helping wxWidgets to improve the library we depend on. We need our
own clone of wxWidgets to be fully patched with all our patches. We
http://wiki.audacityteam.org/wiki/For_Upstream_wxWidgets and
communicate them upstream
So, as RM, I'm deciding we're in freeze-delay. We will freeze later
than originally planned. When we get 437 sorted there will be a new
translation string. Other P2 bug fixes may do that too, so it is not
appropriate to sent the updated pot files to translators yet.
I'll make a call as to when to move on to freeze later, rather than
set a specific date. We have to have made enough progress for it to
happen.
--James (with RM hat on).

Gale Andrews

2016-11-03 19:09:00 UTC

Thanks for progressing on the certificates. However Is that procedure to
certify documented somewhere, and how many of us can do it? Does it
mean that you will be providing the RC's on Windows and Mac?

Obviously it's better that the RC builds come from the same environment
that produces alpha builds, currently Leland and I. Would signing work
as a post-build process, i.e. you would take Leland's and my builds to
be used for RC's and sign them?

And what does it mean for the users? I'm thinking the Manual FAQ's
could do with some updates in regard to this.

* In the spyware FAQ
http://manual.audacityteam.org/man/faq_about_audacity.html#spyware

we could now provide some extra reassurance

* Do we still have to right-click Audacity after installation and Open
and Open because we are an "unidentified developer", which I
understand depends on paying the developer subscription to Apple?

Post by James Crook
I am not comfortable as RM proceeding to release with 36 P2 bugs. On the
other hand I do not want to delay freeze indefinitely!
Given we're still where we were on these 36 bugs, but do now have the
certs for signing, I'm getting ready for us to move forward again, and
accept that I/we will have way more P2s than we would like for 2.1.3.
http://bugzilla.audacityteam.org/show_bug.cgi?id=1427 - Wording Issues,
needs to be DEVEl-FIXMADE before we freeze.

You (James) created that bug. It has no dependencies so it seems
it's not getting used. Do we need it? Either we put wording bugs on
Bugzilla and use the Wiki Wording page as the thought pad to get
us to agreed wordings, or we don't track wording on Bugzilla and
track them on Wiki.

I suggest purely Wiki tracking. Have "W" ratings for bugs on that
Wiki page. In order to release Audacity, there must be no W1's on
that page, just like there must be no Manual P1's (which we could
call M1's).

Post by James Crook
http://bugzilla.audacityteam.org/show_bug.cgi?id=437 - Write fails
without warning when disk full.
http://bugzilla.audacityteam.org/show_bug.cgi?id=1499 - Linux: ASSERT on
check dependencies, is an apparently solved representative of the Linux
ASSERT bugs, which include 1232 and 1412 and possibly 1509.
I'd like
a) Gale to check the status of these Linux ASSERT bugs.

Asserts are expected on Linux because of the wx Debug Level used.
We just have too many asserts, so naive users are more likely
than before to come across one or more of them.

I suspect we shouldn't litter the Release Notes with individual
ASSERT issues. Rather, have a Summary Assert bug that contains
the single Release Note saying:

* How to continue when you receive an assert and what happens
otherwise.

* Brief descriptions of each assert or perhaps each P3 or P2 assert.

Post by James Crook
b) A recommendation from linux builders as to what updated wording we
should put in the linux build instructions in README.txt.

Do you mean "5. Compilation instructions" in README.txt in the root
of the tree, or something else?

What wording do you want? Are you suggesting that distros should
change the wx Debug Level? I doubt they will.

Gale

Post by James Crook
I think the current instructions are inadequate, given that it is/was
easy to compile with a release version of wxWidgets that nevertheless
has ASSERTs in it.
With these dealt with, I'd be happier about moving forward into freeze.
We would at least be down from the 36 open P2s.
--James

James Crook

2016-11-03 20:32:36 UTC

Thanks for progressing on the certificates. However Is that procedure to
certify documented somewhere,

No.

Post by Gale Andrews
and how many of us can do it?

Just me.
The signing will be by whoever's cert is used. We do not have an
official Audacity organisation that can undertake the necessary legal
agreements as an organisation, so it has to be signing by an individual
in their capacity as an individual (and that's what I have gone for).

Post by Gale Andrews
Does it mean that you will be providing the RC's on Windows and Mac?

Yes.

Post by Gale Andrews
Obviously it's better that the RC builds come from the same environment that produces alpha builds, currently Leland and I. Would signing work as a post-build process, i.e. you would take Leland's and my builds to
be used for RC's and sign them?

It is easy for Windows, possibly hard for Mac (because the easy way is
to get XCode to do the signing at the time you build). However I think
it is bad practice to sign a build I haven't built, so I won't be doing
that.

Post by Gale Andrews
And what does it mean for the users? I'm thinking the Manual FAQ's
could do with some updates in regard to this.
* In the spyware FAQ
http://manual.audacityteam.org/man/faq_about_audacity.html#spyware
we could now provide some extra reassurance
* Do we still have to right-click Audacity after installation and Open
and Open because we are an "unidentified developer", which I
understand depends on paying the developer subscription to Apple?

I've paid the money to Apple, so it should be that we don't see
'unidentified developer' any more.
Ditto with Windows.

--James.

Vaughan Johnson

2016-11-03 21:45:53 UTC

Thanks for your work on this, James.

===

James: ""We do not have an
official Audacity organisation that can undertake the necessary legal
agreements as an organisation, ..."

Yes, as i've noted for yrs. But it's added complication either way. Problem
with this solution is that it's all and only you, so we lose it if you're
not available.

James: "... so it has to be signing by an individual
in their capacity as an individual (and that's what I have gone for).

Thanks for your initiative.

===

James: "I think
it is bad practice to sign a build I haven't built..."

I agree.

I also see Gale's concern about RC's & Nightlies ("alpha builds"). I
expect it will be fine if the nightlies are still built by current
builders, but there's a chance... I guess you're confident about them,
that any problems will be found in RC's. Yes?

===

James: "I've paid the money to Apple, so it should be that we don't see
'unidentified developer' any more.
Ditto with Windows.".

If you're going to use it for Audacity only, we should reimburse you. If
for other things as well, we should partially reimburse you.

Thanks!

- V

Thanks for progressing on the certificates. However Is that procedure to
certify documented somewhere,

No.

Post by Gale Andrews
and how many of us can do it?

Post by Gale Andrews
Does it mean that you will be providing the RC's on Windows and Mac?

Yes.

Post by Gale Andrews
Obviously it's better that the RC builds come from the same environment

that produces alpha builds, currently Leland and I. Would signing work as a
post-build process, i.e. you would take Leland's and my builds to

Post by Gale Andrews
be used for RC's and sign them?

I've paid the money to Apple, so it should be that we don't see
'unidentified developer' any more.
Ditto with Windows.
--James.
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Vaughan Johnson

2016-11-03 21:46:52 UTC

Oh, and btw, I should have moved money aspect to audacity team list. Oops.
At least it was nothing specific. -- V

Post by Vaughan Johnson
Thanks for your work on this, James.
===
James: ""We do not have an
official Audacity organisation that can undertake the necessary legal
agreements as an organisation, ..."
Yes, as i've noted for yrs. But it's added complication either way.
Problem with this solution is that it's all and only you, so we lose it if
you're not available.
James: "... so it has to be signing by an individual
in their capacity as an individual (and that's what I have gone for).
Thanks for your initiative.
===
James: "I think
it is bad practice to sign a build I haven't built..."
I agree.
I also see Gale's concern about RC's & Nightlies ("alpha builds"). I
expect it will be fine if the nightlies are still built by current
builders, but there's a chance... I guess you're confident about them,
that any problems will be found in RC's. Yes?
===
James: "I've paid the money to Apple, so it should be that we don't see
'unidentified developer' any more.
Ditto with Windows.".
If you're going to use it for Audacity only, we should reimburse you. If
for other things as well, we should partially reimburse you.
Thanks!
- V

for

Post by James Crook
release now.

Thanks for progressing on the certificates. However Is that procedure to
certify documented somewhere,

No.

Post by Gale Andrews
and how many of us can do it?

Post by Gale Andrews
Does it mean that you will be providing the RC's on Windows and Mac?

Yes.

Post by Gale Andrews
Obviously it's better that the RC builds come from the same environment

that produces alpha builds, currently Leland and I. Would signing work as a
post-build process, i.e. you would take Leland's and my builds to

Post by Gale Andrews
be used for RC's and sign them?

Gale Andrews

2016-11-03 22:07:39 UTC

Thanks for progressing on the certificates. However Is that procedure to
certify documented somewhere,

No.

Post by Gale Andrews
and how many of us can do it?

I understood from my initial discussions with Digicert that we could
have flexibility over who signed. If not, this isn't a long term solution,
whoever that one person is, presumably requiring someone else
to do all that you have done to get set up, if you ever become
unavailable.

Post by Gale Andrews
Does it mean that you will be providing the RC's on Windows and Mac?

Yes.

So taking those last two answers together, are you taking over
provision of regular Windows and Mac alpha builds? There is some
degree of risk if not, I feel. A possible risk area could be difference
in Visual Studio or Xcode settings, though of course those could
be matched with settings that are currently used for alpha builds

Also there is a video here in regards to Apple codesigning that
you may want to see (after 22 minutes). It may (or may not) be
relevant to the occasional issues reported on Sierra in any
version of Audacity where plugins in Audacity's "Plug-ins" folder
are not seen.

I've paid the money to Apple, so it should be that we don't see
'unidentified developer' any more.
Ditto with Windows.

I agree with Vaughan you should not be out of pocket if those
purchases are only/mainly for Audacity.

I think QA will want to test signed installers well before the RC
stage so that documentation can be updated in time.

Gale

James Crook

2016-11-03 23:00:11 UTC

Post by Gale Andrews
I understood from my initial discussions with Digicert that we could
have flexibility over who signed.

Only if we share the key, and in my view that reduces the security of
the key too much.

Post by Gale Andrews
If not, this isn't a long term solution, whoever that one person is, presumably requiring someone else
to do all that you have done to get set up, if you ever become unavailable.

I think we have bigger long term problems than that one Gale. The
signing https://en.wikipedia.org/wiki/Bus_factor problem is reasonably
fixable by someone else reading the online docs and doing those steps.
The main work for me was getting a Mac and getting set up to build on
it. The certs and signing is mostly about finding the right docs about
signing and certs online.

Post by Gale Andrews
So taking those last two answers together, are you taking over
provision of regular Windows and Mac alpha builds? There is some
degree of risk if not, I feel. A possible risk area could be
difference in Visual Studio or Xcode settings, though of course those
could be matched with settings that are currently used for alpha builds

No I don't plan to take over provision of regular Windows and Mac alpha
builds.
For now alphas should continue to be unsigned and people should be told
to check the checksum.

I don't think we should have an automated build that signs with a
paid-for cert.

Post by Gale Andrews
Also there is a video here in regards to Apple codesigning that
you may want to see (after 22 minutes). It may (or may not) be
relevant to the occasional issues reported on Sierra in any
version of Audacity where plugins in Audacity's "Plug-ins" folder
are not seen.
I agree with Vaughan you should not be out of pocket if those
purchases are only/mainly for Audacity.
I think QA will want to test signed installers well before the RC
stage so that documentation can be updated in time.

So I should do some signed builds before we get into RCs. I should
anyway, as there is always risk of me not building RCs with
accessibility or some other glitch like that.

--James.

Gale Andrews

2016-11-04 00:39:47 UTC

Post by Gale Andrews
I understood from my initial discussions with Digicert that we could
have flexibility over who signed.

Only if we share the key, and in my view that reduces the security of
the key too much.

I understood that those who could share had to be specified before
the cert was obtained, but I'm sure you went into that and sharing
risks in more detail than me.

Well, we're now declaring signing as mandatory for release, so
before release of 2.1.3, a mention of signing should I think go into
http://wiki.audacityteam.org/wiki/Release_Process and the
Mac/Win sub-pages thereof.

Post by James Crook
The main work for me was getting a Mac and getting set up to build on
it. The certs and signing is mostly about finding the right docs about
signing and certs online.

No I don't plan to take over provision of regular Windows and Mac alpha
builds.
For now alphas should continue to be unsigned and people should be told
to check the checksum.

So, let's identify any risk from having different build environments
at the final stages of release cycles.

What potential problems, if any, and mitigations do you see?

Post by James Crook
I don't think we should have an automated build that signs with a
paid-for cert.

So does that mean an automated build e.g. cross-compiled
on Linux or on a Windows build server is off the agenda?

Do you see a "pre-release/KTT" alpha release as requiring
a certificate? I guess probably yes if we plan to get it out
quite widely.

Gale

So I should do some signed builds before we get into RCs. I should
anyway, as there is always risk of me not building RCs with
accessibility or some other glitch like that.
--James.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-11-04 09:28:05 UTC

Post by Gale Andrews
So, let's identify any risk from having different build environments
at the final stages of release cycles.
What potential problems, if any, and mitigations do you see?

Biggest risk is 'building wxWidgets different ways', for example with
different patches and options.
There is also possibility of different build tools, e.g. VS2013 express
vs VS2015 pro or different XCode versions.

We can reduce the risk on different patched versions of wx by using a
patched version from our GitHub repo.
We can tighten up the build instructions so that instead of giving a
range of versions to choose from we specify the version we have tested with.

Post by James Crook
I don't think we should have an automated build that signs with a
paid-for cert.

So does that mean an automated build e.g. cross-compiled on Linux or on a Windows build server is off the agenda?

It can be an unsigned version, or self-signed. Either way we are not
testing the signing, but can be testing other aspects.

Post by Gale Andrews
Do you see a "pre-release/KTT" alpha release as requiring a certificate?

Yes.

Post by Gale Andrews
I guess probably yes if we plan to get it out quite widely.

--James.

Steve the Fiddle

2016-11-04 11:26:20 UTC

Is this requirement for digital signing by a paid up Apple developer
"tivoizing" Audacity on OS X?
https://en.wikipedia.org/wiki/Tivoization
Is Audacity really "_free_ open source software" on Sierra?
https://en.wikipedia.org/wiki/Tivoization#GPLv3

Steve

Post by Gale Andrews
So, let's identify any risk from having different build environments
at the final stages of release cycles.
What potential problems, if any, and mitigations do you see?

Biggest risk is 'building wxWidgets different ways', for example with
different patches and options.
There is also possibility of different build tools, e.g. VS2013 express
vs VS2015 pro or different XCode versions.
We can reduce the risk on different patched versions of wx by using a
patched version from our GitHub repo.
We can tighten up the build instructions so that instead of giving a
range of versions to choose from we specify the version we have tested with.

Post by James Crook
I don't think we should have an automated build that signs with a
paid-for cert.

So does that mean an automated build e.g. cross-compiled on Linux or on a Windows build server is off the agenda?

It can be an unsigned version, or self-signed. Either way we are not
testing the signing, but can be testing other aspects.

Post by Gale Andrews
Do you see a "pre-release/KTT" alpha release as requiring a certificate?

Yes.

Post by Gale Andrews
I guess probably yes if we plan to get it out quite widely.

--James.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-11-04 12:31:01 UTC

Post by Steve the Fiddle
Is this requirement for digital signing by a paid up Apple developer
"tivoizing" Audacity on OS X?

I'm 99% sure it's not.

No more than our 'no P1 bugs' requirement for release, we don't require
people building from our source for OSX to sign their DMGs, so WE are
not Tivoizing Audacity.

I'm still running Yosemite so have not tested the changes in Sierra. As
I understand it users can still run unsigned software under Sierra, if
they so choose, so APPLE have not tivoized Sierra yet. See:
http://apple.stackexchange.com/questions/243687/allow-applications-downloaded-from-anywhere-in-macos-sierra
I suppose you can argue they are gradually Tivoizing by making it
increasingly inconvenient.
IF APPLE later did prevent running of unsigned software on Sierra, they
would have tivoized Sierra.

My decision as RM that we need to sign dmgs/installers in future isn't
caused by the inconvenience of running unsigned apps under Sierra.
Rather it's a response to the hack at FossHub.

IF Apple do Tivoize Mac, I think we should continue to provide signed
Audacity for Mac. Tivoization is contrary to the spirit of Open Source,
but not to the letter of GPL v2. With Tivoization, Apple can introduce
any terms and conditions they like, and at some point we might decide
those terms and conditions are unacceptable. The Tivoization itself
isn't the problem, it's the possible extra T&Cs.

--James.

Steve the Fiddle

2016-11-04 14:40:46 UTC

Post by Steve the Fiddle
Is this requirement for digital signing by a paid up Apple developer
"tivoizing" Audacity on OS X?

I'm 99% sure it's not.
No more than our 'no P1 bugs' requirement for release, we don't require
people building from our source for OSX to sign their DMGs, so WE are
not Tivoizing Audacity.

I agree, WE are not Tivoizing Audacity

Post by James Crook
I'm still running Yosemite so have not tested the changes in Sierra. As
I understand it users can still run unsigned software under Sierra, if
http://apple.stackexchange.com/questions/243687/allow-applications-downloaded-from-anywhere-in-macos-sierra

Unfortunately, the Ctrl+Click / Right click workaround is no longer
enough with Sierra.
That allows Audacity to launch, but without LAME, FFmpeg or Nyquist.

I can get past that by opening the terminal and typing:
xattr -r -d com.apple.quarantine <path-to-audacity>

Post by James Crook
I suppose you can argue they are gradually Tivoizing by making it
increasingly inconvenient.

I imagine that requiring cryptic terminal commands is not only
"inconvenient" but way beyond most Mac users. It seems pretty obvious
that Apple don't want their customers using free software, though
they're prepared to turn a blind eye for a small fee.

Post by James Crook
IF APPLE later did prevent running of unsigned software on Sierra, they
would have tivoized Sierra.
My decision as RM that we need to sign dmgs/installers in future isn't
caused by the inconvenience of running unsigned apps under Sierra.
Rather it's a response to the hack at FossHub.
IF Apple do Tivoize Mac, I think we should continue to provide signed
Audacity for Mac.

If we continue to provide Mac binaries then I think we have no choice
but to pay the tax.
What galls me is that we chose to not charge Mac users, but Apple
still charges us for providing software for their OS. Of course if we
were a business, we would pass the cost on to the customer, (No wonder
Apple products are overpriced - their logo says it all: they take a
bite out before passing it on to the customer).

Steve

Post by James Crook
Tivoization is contrary to the spirit of Open Source,
but not to the letter of GPL v2. With Tivoization, Apple can introduce
any terms and conditions they like, and at some point we might decide
those terms and conditions are unacceptable. The Tivoization itself
isn't the problem, it's the possible extra T&Cs.
--James.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-11-04 15:39:03 UTC

Post by Steve the Fiddle
If we continue to provide Mac binaries then I think we have no choice
but to pay the tax.

Yes. That's how I see it too.

Post by Steve the Fiddle
What galls me is that we chose to not charge Mac users, but Apple
still charges us for providing software for their OS.

Martyn Shaw

2016-11-07 00:11:19 UTC

An interesting discussion, thanks guys!

Martyn

Post by Steve the Fiddle
If we continue to provide Mac binaries then I think we have no choice
but to pay the tax.

Yes. That's how I see it too.

Post by Steve the Fiddle
What galls me is that we chose to not charge Mac users, but Apple
still charges us for providing software for their OS.

I look at it slightly differently. $99 is a tiny sum for Apple, far far
less than their typical store revenue per developer. Apple aren't
particularly interested in making a profit from the developer fee.
They are though very interested in keeping malware out. A developer
identity fee acts as a barrier. They have traceability on all software
to a credit card used to pay for the id. They can also track the use of
any signed malware, because gatekeeper will be checking the certs of any
software. The $99 fee in my view is in effect a sign up fee to be part
of apple's anti malware initiative, rather than an extra piece of
profiteering by Apple. If they waived the fee for open source software
then they wouldn't have traceability to a credit card.
--James.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2016-11-04 15:40:27 UTC

Post by Gale Andrews
So, let's identify any risk from having different build environments
at the final stages of release cycles.
What potential problems, if any, and mitigations do you see?

OK. I don't believe I am making any mistakes in building Widgets
but if we have patched versions posted for Windows and Mac,
please point me to them..

I'm using VS2013 Community Edition Version 12.0.40629.00
Update 5 on Windows 10.

If it makes any difference, I use devenv to build at the command-line
(and "hope" I will manage to script the entire process soon).

One detail: I build with the Audacity Platform Toolset set to
"Windows XP (v120_xp)" but the Platform Toolset for the wxWidgets
projects is the default "Visual Studio 2013 (v120)". I don't think
we have decided yet if that is a problem. Setting the wxWidgets
toolset back to XP "might" potentially cause some issue on Vista
and later, I suppose.

I don't know Leland's version of XCode and his set up details.
My Xcode is 7.1.

Post by James Crook
We can tighten up the build instructions so that instead of giving a
range of versions to choose from we specify the version we have tested with.

Post by James Crook
I don't think we should have an automated build that signs with a
paid-for cert.

So does that mean an automated build e.g. cross-compiled on Linux or on a Windows build server is off the agenda?

It can be an unsigned version, or self-signed.

What is self-signed? Presumably it still throws "unknown publisher"
messages on Windows?

I assume one issue with an automated build done by a service
provider is that we may not be able to specify the kind of details
noted above.

Gale

Post by James Crook
Either way we are not testing the signing, but can be testing other aspects.

Post by Gale Andrews
Do you see a "pre-release/KTT" alpha release as requiring a certificate?

Yes.

Post by Gale Andrews
I guess probably yes if we plan to get it out quite widely.

--James.

James Crook

2016-11-04 17:57:42 UTC

Post by Gale Andrews
OK. I don't believe I am making any mistakes in building Widgets
but if we have patched versions posted for Windows and Mac,
please point me to them..

For Mac I am using
https://github.com/JamesCrook/wxWidgets/tree/AudacityPatched3.0.2

For Windows I am not sure what I am using, except that it is wrong in
that it is not compiled with accessibility enabled. So I need to fix
that. My intent is to add any required patches to the above git branch,
and use that on all platforms, so we have a single patched branch of
3..0.2 for all platforms. And move it from my repo to main repo.

Post by Gale Andrews
I'm using VS2013 Community Edition Version 12.0.40629.00
Update 5 on Windows 10.

I'm using Microsoft Visual Studio Express 2013 for Windows Desktop
Version 12.0.40629.00 Update 5
Visual C++ 2013 06157-004-0441005-02085

Post by Gale Andrews
If it makes any difference, I use devenv to build at the command-line
(and "hope" I will manage to script the entire process soon).

I build from the GUI.

Post by Gale Andrews
One detail: I build with the Audacity Platform Toolset set to
"Windows XP (v120_xp)" but the Platform Toolset for the wxWidgets
projects is the default "Visual Studio 2013 (v120)". I don't think
we have decided yet if that is a problem. Setting the wxWidgets
toolset back to XP "might" potentially cause some issue on Vista
and later, I suppose.

I use Visual Studio 2013 (v120) on both.

Post by Gale Andrews
I don't know Leland's version of XCode and his set up details.
My Xcode is 7.1.
xcodebuild -version

XCode 6.4
Build version 6E35b

Post by Gale Andrews
gcc -v

Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)

I'm building/testing on Yosemite.

Post by Gale Andrews
What is self-signed?

Signed with a fake cert that you create using certutil.

Post by Gale Andrews
Presumably it still throws "unknown publisher"
messages on Windows?

Yes, unless you install/trust the fake cert.
It is said to be useful for companies for in house software.

Post by Gale Andrews
I assume one issue with an automated build done by a service provider is that we may not be able to specify the kind of details noted above.

You can get dedicated Mac hosting for €69/month. On those you can set
exactly the software you want. We could run jenkins on it to do the CI
builds. For no monthly fee we could use ngrok
https://developer.github.com/webhooks/configuring/ so that one of our
home Macs could monitor GitHub and do CI builds.

Also for free, Travis will build
https://docs.travis-ci.com/user/osx-ci-environment/#OS-X-Version and we
can select which version of xcode
https://docs.travis-ci.com/user/osx-ci-environment/ and can deploy to a
URL of our choosing using google cloud storage
https://docs.travis-ci.com/user/deployment/gcs/ or AWS CodeDeploy
https://docs.travis-ci.com/user/deployment/codedeploy/

--James.

Post by Gale Andrews
Gale

Post by James Crook
Either way we are not testing the signing, but can be testing other aspects.

Post by Gale Andrews
Do you see a "pre-release/KTT" alpha release as requiring a certificate?

Yes.

Post by Gale Andrews
I guess probably yes if we plan to get it out quite widely.

--James.

Gale Andrews

2016-11-04 19:13:56 UTC

Post by Gale Andrews
OK. I don't believe I am making any mistakes in building Widgets
but if we have patched versions posted for Windows and Mac,
please point me to them..

For Mac I am using
https://github.com/JamesCrook/wxWidgets/tree/AudacityPatched3.0.2
For Windows I am not sure what I am using, except that it is wrong in
that it is not compiled with accessibility enabled. So I need to fix
that. My intent is to add any required patches to the above git branch,
and use that on all platforms, so we have a single patched branch of
3..0.2 for all platforms. And move it from my repo to main repo.

+1 to that last paragraph. It also solves the problem of not having
an integrated patch for wxMac for those who want to apply all
patches.

I assume you can resolve any conflicts where Mac and Windows
differ in the same file by setting platform defines.

Post by Gale Andrews
I'm using VS2013 Community Edition Version 12.0.40629.00
Update 5 on Windows 10.

I'm using Microsoft Visual Studio Express 2013 for Windows Desktop
Version 12.0.40629.00 Update 5
Visual C++ 2013 06157-004-0441005-02085

Post by Gale Andrews
If it makes any difference, I use devenv to build at the command-line
(and "hope" I will manage to script the entire process soon).

I build from the GUI.

I don't "think" GUI versus command-line makes a difference but
obviously I am no expert on that. Hints are welcome.

I no longer want to manually supply regular Audacity alpha for
Windows, but fully scripted (or almost so, where I am now)
is fine.

I use Visual Studio 2013 (v120) on both.

So your version run on XP? If so you would have to change.
the Audacity toolset.

And do you want me to change to build wxWidgets with (v120_xp).
or should we research it first, or leave a decision until after 2.1.3?
I'm not keen to fix for 2.1.3 something that isn't apparently broken.
Release Process/Win implies by omission my current setup.

Post by Gale Andrews
I don't know Leland's version of XCode and his set up details.
My Xcode is 7.1.
xcodebuild -version

XCode 6.4
Build version 6E35b

Post by Gale Andrews
gcc -v

Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
I'm building/testing on Yosemite.

The mac/Build.txt states that Xcode 6.4.1 and 7.1 are verified to
work correctly, so that is presumably fine.

Thanks for the replies.

Gale

Post by Gale Andrews
What is self-signed?

Signed with a fake cert that you create using certutil.

Post by Gale Andrews
Presumably it still throws "unknown publisher"
messages on Windows?

Yes, unless you install/trust the fake cert.
It is said to be useful for companies for in house software.

Post by Gale Andrews
I assume one issue with an automated build done by a service provider is that we may not be able to specify the kind of details noted above.

You can get dedicated Mac hosting for €69/month. On those you can set
exactly the software you want. We could run jenkins on it to do the CI
builds. For no monthly fee we could use ngrok
https://developer.github.com/webhooks/configuring/ so that one of our
home Macs could monitor GitHub and do CI builds.
Also for free, Travis will build
https://docs.travis-ci.com/user/osx-ci-environment/#OS-X-Version and we
can select which version of xcode
https://docs.travis-ci.com/user/osx-ci-environment/ and can deploy to a
URL of our choosing using google cloud storage
https://docs.travis-ci.com/user/deployment/gcs/ or AWS CodeDeploy
https://docs.travis-ci.com/user/deployment/codedeploy/
--James.

Post by Gale Andrews
Gale

Post by James Crook
Either way we are not testing the signing, but can be testing other aspects.

Post by Gale Andrews
Do you see a "pre-release/KTT" alpha release as requiring a certificate?

Yes.

Post by Gale Andrews
I guess probably yes if we plan to get it out quite widely.

--James.

James Crook

2016-11-04 20:00:53 UTC

Post by James Crook
I use Visual Studio 2013 (v120) on both.

So your version run on XP? If so you would have to change.
the Audacity toolset.

I would expect my version to NOT run on XP. However I don't have an XP
box to test it on, so I don't know for sure.

Post by Gale Andrews
And do you want me to change to build wxWidgets with (v120_xp).
or should we research it first, or leave a decision until after 2.1.3?
I'm not keen to fix for 2.1.3 something that isn't apparently broken.
Release Process/Win implies by omission my current setup.

No, don't change. I will build wxWidgets with (v120_xp) once I have the
right source / options.

--James.

Gale Andrews

2016-11-05 00:17:59 UTC

Post by James Crook
I use Visual Studio 2013 (v120) on both.

So your version run on XP? If so you would have to change.
the Audacity toolset.

I would expect my version to NOT run on XP.

Oops my text got messed up. I too would expect your Audacity version
NOT to run on XP if built with the (v120) toolset. We agreed IIRC to
support XP for 2.1.3, but for that to be final release for XP.

My build was OK on XP SP3, last time I checked.

Gale

Post by James Crook
However I don't have an XP box to test it on, so I don't know for sure.

No, don't change. I will build wxWidgets with (v120_xp) once I have the
right source / options.
--James.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-11-03 20:32:45 UTC

Post by James Crook
http://bugzilla.audacityteam.org/show_bug.cgi?id=1427 - Wording Issues,
needs to be DEVEl-FIXMADE before we freeze.

You (James) created that bug.

Yes. "A summary bug to direct people to the wiki page
http://wiki.audacityteam.org/wiki/Wording for issues that are (only)
about the precise choice of wording."

Post by Gale Andrews
It has no dependencies so it seems it's not getting used. Do we need it?

That's your and Peter's call. I've a feeling one of you wanted it for
fear that the wiki-wording bugs would be overlooked by RM. If you are
both confident I won't forget about the wording bugs in wiki then I am
fine with 1427 being closed.

Post by Gale Andrews
Either we put wording bugs on
Bugzilla and use the Wiki Wording page as the thought pad to get
us to agreed wordings, or we don't track wording on Bugzilla and
track them on Wiki.

If you are saying it is not on to have a summary bug (1427) that is
'summarising' wording bugs tracked on wiki, then close it. I do not
want to go back to having 'word bugs' in bugzilla where the tracking
overhead massively dwarfs the work in fixing the individual words.

Post by Gale Andrews
I suggest purely Wiki tracking. Have "W" ratings for bugs on that
Wiki page. In order to release Audacity, there must be no W1's on
that page, just like there must be no Manual P1's (which we could
call M1's).

+1. I am fine with that.
Equally I am fine with 'going in the other direction' and having a
bugzilla summary bug to remind RM that manual currently has M1's M2's'...

--James.

Gale Andrews

2016-11-03 21:40:44 UTC

Let's just close 1427 rather than have a non-standard summary bug
with no dependencies.

We both agree we don't want wording bugs themselves on Bugzilla.
Peter did want that, but in exchange for not listing them on Bugzilla
I'd agreed, if you recall, to be responsible for committing agreed
changes that were listed on the Wiki wording page.

So they won't be forgotten. I'd say though it isn't always clear
on that Wiki page when a rewording has been agreed,

I'm sure Peter would (and should) shout if Manual P1's were still
open.

Gale

Post by James Crook
http://bugzilla.audacityteam.org/show_bug.cgi?id=1427 - Wording Issues,
needs to be DEVEl-FIXMADE before we freeze.

Post by Gale Andrews
You (James) created that bug.
Yes. "A summary bug to direct people to the wiki page
http://wiki.audacityteam.org/wiki/Wording for issues that are (only) about
the precise choice of wording."
It has no dependencies so it seems it's not getting used. Do we need it?

That's your and Peter's call. I've a feeling one of you wanted it for fear
that the wiki-wording bugs would be overlooked by RM. If you are both
confident I won't forget about the wording bugs in wiki then I am fine with
1427 being closed.

If you are saying it is not on to have a summary bug (1427) that is
'summarising' wording bugs tracked on wiki, then close it. I do not want to
go back to having 'word bugs' in bugzilla where the tracking overhead
massively dwarfs the work in fixing the individual words.

+1. I am fine with that.
Equally I am fine with 'going in the other direction' and having a bugzilla
summary bug to remind RM that manual currently has M1's M2's'...
--James.
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Peter Sampson

2016-11-04 16:24:07 UTC

Post by Gale Andrews
Let's just close 1427 rather than have a non-standard summary bug
with no dependencies.

Post by Gale Andrews
We both agree we don't want wording bugs themselves on Bugzilla.
Peter did want that, but in exchange for not listing them on Bugzilla
I'd agreed, if you recall, to be responsible for committing agreed
changes that were listed on the Wiki wording page.

I used to want that - but I was persuaded that it would be better to use
the Wording page - and I am happy with that. I don'y need a perma-bug
to remind me to look at it fairly regularly.

Post by Gale Andrews
I'm sure Peter would (and should) shout if Manual P1's were still
open.

I will, I will ;-))

Peter

James Crook

2016-11-03 20:33:40 UTC

Asserts are expected on Linux because of the wx Debug Level used.
We just have too many asserts, so naive users are more likely
than before to come across one or more of them.

I think ASSERTs from within wxWidgets code, with a release build, should
NOT be expected.
If the ASSERTS are benign (e.g. claiming a resource we already have)
then they should NOT be popping up for the user.
If the ASSERTS are not benign, then we must understand/fix them.
For OSX I think we have disabled the asserts rather than actually fixing
them.
Why do we have them for Linux and not for Windows? Does it mean that
wxWidgets on Linux is very ropey?

Post by Gale Andrews
I suspect we shouldn't litter the Release Notes with individual
ASSERT issues. Rather, have a Summary Assert bug that contains
* How to continue when you receive an assert and what happens
otherwise.
* Brief descriptions of each assert or perhaps each P3 or P2 assert.

It seems to me that giving adequate build instructions would fix
http://bugzilla.audacityteam.org/show_bug.cgi?id=1499
and the related Linux ASSERTs. So shouldn't we do that instead?

Post by James Crook
b) A recommendation from linux builders as to what updated wording we
should put in the linux build instructions in README.txt.

Do you mean "5. Compilation instructions" in README.txt in the root
of the tree, or something else?

That's the one.

Post by Gale Andrews
What wording do you want? Are you suggesting that distros should
change the wx Debug Level? I doubt they will.

Maybe not, but we can instruct users to upgrade from 14.04.1 to 14.04.5
if on Ubuntu - or else build and install their own copy of wxWidgets if
they want to stay on 14.04.1. Or someone with automakefu can put a
'precondition' into autoconfig.

My view is that if we instruct builders to avoid using an ASSERTY
wxWidgets, just as we instruct them to avoid using wx3.1.0, then we can
close these bugs. Do you think that's right?

--James.

Gale Andrews

2016-11-04 19:59:41 UTC

Asserts are expected on Linux because of the wx Debug Level used.
We just have too many asserts, so naive users are more likely
than before to come across one or more of them.

I think the basic reason is that wxWidgets has long defaulted
to that debug level on Linux (and now does on Windows and
Mac, IIRC) and we haven't wanted to exert control over what
Linux distros do.

Post by James Crook
Does it mean that wxWidgets on Linux is very ropey?

I don't "think" so as such, but because we don't control the exact
version of wxWidgets used (e.g. system 3.0.0. or vanilla 3.0.2
from wxWidgets), or what Widgets configuration arguments are
set, wxWidgets stability could vary significantly.

Accordingly you could argue for retaining the asserts so
we know if e.g. something is going wrong in Fedora's packaged
version of Audacity built with a specific wx3.0.x, but not in
HEAD built with vanilla wx3.0.2 under default ./configure.

It seems to me that giving adequate build instructions would fix
http://bugzilla.audacityteam.org/show_bug.cgi?id=1499
and the related Linux ASSERTs. So shouldn't we do that instead?