Accessibility of Spectral Selection Toolbar at high frequencies

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

Gale
Administrator
The problem though is that for "early adopters" I think we have
agreed there should be only one experimental build per cycle
and that most likely it will roll up all the "probably not for next
release" features into that one build.

I think what Steve is describing is more like a build that "we"
or any signed-up "advanced testers" would test, which would
be hosted on the author's fork of Audacity, and which would
(after any changes) appear in the mid-term build or the "rollup".



Gale


On 18 April 2017 at 20:07, Steve the Fiddle <[hidden email]> wrote:

> On 18 April 2017 at 18:32, Gale Andrews <[hidden email]> wrote:
>> On 18 April 2017 at 12:24, Steve the Fiddle <[hidden email]> wrote:
>>> On 18 April 2017 at 12:06, James Crook <[hidden email]> wrote:
>>>> On 4/18/2017 10:46 AM, Steve the Fiddle wrote:
>>>>> On 18 April 2017 at 09:50, James Crook <[hidden email]> wrote:
>>>>>> I think it is fine/good that we distinguish public betas (which have not
>>>>>> been through a full QA process) from releases (which have).
>>>>>>
>>>>>> I am fine with phasing out KTT as a term.  At the moment only we know
>>>>>> what KTT means.  'kicking the tyres' is neither a good nor reliable
>>>>>> practice for evaluating a car, motorbike or bicycle.
>>>>> Very true. More like an MOT would be better :-)
>>>>
>>>> :-)
>>>>
>>>> And the American 'mot' for MOT is I think is 'smog test'.  So I say
>>>> Vaughan's point still stands.   And even if we call it a smog-test-build
>>>> people in europe aren't going to know what it is. 'Mid-term-beta' or
>>>> 'mid-term-build' probably will do - using 'term' rather than 'release
>>>> cycle' to be vaguer, since Vaughan has cast doubt on what a 'release
>>>> cycle' is too.
>>>
>>> In case there's confusion, I didn't mean to suggest that we call it an
>>> "MOT", but that testing of a mid-term beta should be a proper safety
>>> check of critical parts (like an MOT in the UK), rather than "kicking
>>> the tyres".
>>>
>>> I'm in agreement with what others have said - if we have a mid-term
>>> beta (and no experimental branch or any other "special" builds), then
>>> simply call it a "beta".
>>
>> What if we have both? The mid-term pre-release (calling it
>> how I think of it) must be called the same in both cases.
>
> If we have "experimental builds", in my opinion they should be from an
> experimental branch of https://github.com/audacity/audacity
> The name will then be obvious, based on the name of the branch.
>
> For example, if we have an experimental MIDI branch at:
> https://github.com/audacity/audacity/tree/midi
> and we make a beta build from that branch, then the build would be
> called something along the lines of:
> "Audacity MIDI 2.2.0-beta"
>
> Steve
>
>>
>> To me the user perception of stability of these builds is highly
>> relevant to the willingness of users to test them. To call them
>> "beta", we would have to explain the difference between beta
>> and alpha, to assist those users who state that that the
>> nightlies are betas.
>>
>> I would expect the KTT stability to be high, between a release
>> and what we had in most of the 1.3 series. We want a term
>> that suggests that.
>>
>> I like "mid-term build" and "experimental build" myself. There
>> is a clear distinction in perceived stability between those. Have
>> I got it right that KTT is pure HEAD?  It would be the same
>> as an alpha built at the same revision?
>>
>>
>>
>> Gale
>>
>>
>>>> Anyway, the right 'mot' for MOT or whatever is all moot, if we don't
>>>> actually have one, and whether we have one or not seems a more pressing
>>>> question.  One thing that came out of an off-list discussion with Gale
>>>> is that we can use the suffix -m for a mid term build and -x for an
>>>> experimental/exploratory build.  That could help reduce confusion about
>>>> the purpose of each.  -m is expected to go into the upcoming release.
>>>> -x additionally has a developers plans/exploratory-ideas that are
>>>> unlikely to be in the upcoming release (preview, of interest to early
>>>> adopters, who may want to get involved in helping us refine ideas and
>>>> fix issues).
>>>>
>>>> For 2.2.0 I think we will likely have just an -m, with the MIDI_OUT in
>>>> it too.  There will be plenty new in the -m for 'early adopters'.  If
>>>> MIDI_OUT is looking unlikely for 2.2.0, then it should be in an -x, but
>>>> it being in the -m would be far better.
>>>>
>>>> --James.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

Stevethefiddle
On 18 April 2017 at 20:51, Gale Andrews <[hidden email]> wrote:
> The problem though is that for "early adopters" I think we have
> agreed there should be only one experimental build per cycle
> and that most likely it will roll up all the "probably not for next
> release" features into that one build.

Why is that a problem?
If it is branch of https://github.com/audacity/audacity then it will
have a name.

>
> I think what Steve is describing is more like a build that "we"
> or any signed-up "advanced testers" would test, which would
> be hosted on the author's fork of Audacity, and which would
> (after any changes) appear in the mid-term build or the "rollup".

I didn't mention "fork" or "author". I was very careful to refer
specifically to a branch of https://github.com/audacity/audacity
If we start dealing with semi-official / auteur / friendly forks /
whatever you want to call them, it all becomes very messy imo (as
evidenced by the tens of thousands of words discussing DA).

Steve

>
>
>
> Gale
>
>
> On 18 April 2017 at 20:07, Steve the Fiddle <[hidden email]> wrote:
>> On 18 April 2017 at 18:32, Gale Andrews <[hidden email]> wrote:
>>> On 18 April 2017 at 12:24, Steve the Fiddle <[hidden email]> wrote:
>>>> On 18 April 2017 at 12:06, James Crook <[hidden email]> wrote:
>>>>> On 4/18/2017 10:46 AM, Steve the Fiddle wrote:
>>>>>> On 18 April 2017 at 09:50, James Crook <[hidden email]> wrote:
>>>>>>> I think it is fine/good that we distinguish public betas (which have not
>>>>>>> been through a full QA process) from releases (which have).
>>>>>>>
>>>>>>> I am fine with phasing out KTT as a term.  At the moment only we know
>>>>>>> what KTT means.  'kicking the tyres' is neither a good nor reliable
>>>>>>> practice for evaluating a car, motorbike or bicycle.
>>>>>> Very true. More like an MOT would be better :-)
>>>>>
>>>>> :-)
>>>>>
>>>>> And the American 'mot' for MOT is I think is 'smog test'.  So I say
>>>>> Vaughan's point still stands.   And even if we call it a smog-test-build
>>>>> people in europe aren't going to know what it is. 'Mid-term-beta' or
>>>>> 'mid-term-build' probably will do - using 'term' rather than 'release
>>>>> cycle' to be vaguer, since Vaughan has cast doubt on what a 'release
>>>>> cycle' is too.
>>>>
>>>> In case there's confusion, I didn't mean to suggest that we call it an
>>>> "MOT", but that testing of a mid-term beta should be a proper safety
>>>> check of critical parts (like an MOT in the UK), rather than "kicking
>>>> the tyres".
>>>>
>>>> I'm in agreement with what others have said - if we have a mid-term
>>>> beta (and no experimental branch or any other "special" builds), then
>>>> simply call it a "beta".
>>>
>>> What if we have both? The mid-term pre-release (calling it
>>> how I think of it) must be called the same in both cases.
>>
>> If we have "experimental builds", in my opinion they should be from an
>> experimental branch of https://github.com/audacity/audacity
>> The name will then be obvious, based on the name of the branch.
>>
>> For example, if we have an experimental MIDI branch at:
>> https://github.com/audacity/audacity/tree/midi
>> and we make a beta build from that branch, then the build would be
>> called something along the lines of:
>> "Audacity MIDI 2.2.0-beta"
>>
>> Steve
>>
>>>
>>> To me the user perception of stability of these builds is highly
>>> relevant to the willingness of users to test them. To call them
>>> "beta", we would have to explain the difference between beta
>>> and alpha, to assist those users who state that that the
>>> nightlies are betas.
>>>
>>> I would expect the KTT stability to be high, between a release
>>> and what we had in most of the 1.3 series. We want a term
>>> that suggests that.
>>>
>>> I like "mid-term build" and "experimental build" myself. There
>>> is a clear distinction in perceived stability between those. Have
>>> I got it right that KTT is pure HEAD?  It would be the same
>>> as an alpha built at the same revision?
>>>
>>>
>>>
>>> Gale
>>>
>>>
>>>>> Anyway, the right 'mot' for MOT or whatever is all moot, if we don't
>>>>> actually have one, and whether we have one or not seems a more pressing
>>>>> question.  One thing that came out of an off-list discussion with Gale
>>>>> is that we can use the suffix -m for a mid term build and -x for an
>>>>> experimental/exploratory build.  That could help reduce confusion about
>>>>> the purpose of each.  -m is expected to go into the upcoming release.
>>>>> -x additionally has a developers plans/exploratory-ideas that are
>>>>> unlikely to be in the upcoming release (preview, of interest to early
>>>>> adopters, who may want to get involved in helping us refine ideas and
>>>>> fix issues).
>>>>>
>>>>> For 2.2.0 I think we will likely have just an -m, with the MIDI_OUT in
>>>>> it too.  There will be plenty new in the -m for 'early adopters'.  If
>>>>> MIDI_OUT is looking unlikely for 2.2.0, then it should be in an -x, but
>>>>> it being in the -m would be far better.
>>>>>
>>>>> --James.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

Gale
Administrator
On 18 April 2017 at 21:05, Steve the Fiddle <[hidden email]> wrote:
> On 18 April 2017 at 20:51, Gale Andrews <[hidden email]> wrote:
>> The problem though is that for "early adopters" I think we have
>> agreed there should be only one experimental build per cycle
>> and that most likely it will roll up all the "probably not for next
>> release" features into that one build.
>
> Why is that a problem?
> If it is branch of https://github.com/audacity/audacity then it will
> have a name.

An extreme example, with more contributors than now

midi_out-magnifier-multi_views-effects_rack-menu_munger


>> I think what Steve is describing is more like a build that "we"
>> or any signed-up "advanced testers" would test, which would
>> be hosted on the author's fork of Audacity, and which would
>> (after any changes) appear in the mid-term build or the "rollup".
>
> I didn't mention "fork" or "author". I was very careful to refer
> specifically to a branch of https://github.com/audacity/audacity
> If we start dealing with semi-official / auteur / friendly forks /
> whatever you want to call them, it all becomes very messy imo (as
> evidenced by the tens of thousands of words discussing DA).

Well then, DA would have to come into audacity/audacity if it was
used for the rollup.


Gale



>> On 18 April 2017 at 20:07, Steve the Fiddle <[hidden email]> wrote:
>>> On 18 April 2017 at 18:32, Gale Andrews <[hidden email]> wrote:
>>>> On 18 April 2017 at 12:24, Steve the Fiddle <[hidden email]> wrote:
>>>>> On 18 April 2017 at 12:06, James Crook <[hidden email]> wrote:
>>>>>> On 4/18/2017 10:46 AM, Steve the Fiddle wrote:
>>>>>>> On 18 April 2017 at 09:50, James Crook <[hidden email]> wrote:
>>>>>>>> I think it is fine/good that we distinguish public betas (which have not
>>>>>>>> been through a full QA process) from releases (which have).
>>>>>>>>
>>>>>>>> I am fine with phasing out KTT as a term.  At the moment only we know
>>>>>>>> what KTT means.  'kicking the tyres' is neither a good nor reliable
>>>>>>>> practice for evaluating a car, motorbike or bicycle.
>>>>>>> Very true. More like an MOT would be better :-)
>>>>>>
>>>>>> :-)
>>>>>>
>>>>>> And the American 'mot' for MOT is I think is 'smog test'.  So I say
>>>>>> Vaughan's point still stands.   And even if we call it a smog-test-build
>>>>>> people in europe aren't going to know what it is. 'Mid-term-beta' or
>>>>>> 'mid-term-build' probably will do - using 'term' rather than 'release
>>>>>> cycle' to be vaguer, since Vaughan has cast doubt on what a 'release
>>>>>> cycle' is too.
>>>>>
>>>>> In case there's confusion, I didn't mean to suggest that we call it an
>>>>> "MOT", but that testing of a mid-term beta should be a proper safety
>>>>> check of critical parts (like an MOT in the UK), rather than "kicking
>>>>> the tyres".
>>>>>
>>>>> I'm in agreement with what others have said - if we have a mid-term
>>>>> beta (and no experimental branch or any other "special" builds), then
>>>>> simply call it a "beta".
>>>>
>>>> What if we have both? The mid-term pre-release (calling it
>>>> how I think of it) must be called the same in both cases.
>>>
>>> If we have "experimental builds", in my opinion they should be from an
>>> experimental branch of https://github.com/audacity/audacity
>>> The name will then be obvious, based on the name of the branch.
>>>
>>> For example, if we have an experimental MIDI branch at:
>>> https://github.com/audacity/audacity/tree/midi
>>> and we make a beta build from that branch, then the build would be
>>> called something along the lines of:
>>> "Audacity MIDI 2.2.0-beta"
>>>
>>> Steve
>>>
>>>>
>>>> To me the user perception of stability of these builds is highly
>>>> relevant to the willingness of users to test them. To call them
>>>> "beta", we would have to explain the difference between beta
>>>> and alpha, to assist those users who state that that the
>>>> nightlies are betas.
>>>>
>>>> I would expect the KTT stability to be high, between a release
>>>> and what we had in most of the 1.3 series. We want a term
>>>> that suggests that.
>>>>
>>>> I like "mid-term build" and "experimental build" myself. There
>>>> is a clear distinction in perceived stability between those. Have
>>>> I got it right that KTT is pure HEAD?  It would be the same
>>>> as an alpha built at the same revision?
>>>>
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>>>> Anyway, the right 'mot' for MOT or whatever is all moot, if we don't
>>>>>> actually have one, and whether we have one or not seems a more pressing
>>>>>> question.  One thing that came out of an off-list discussion with Gale
>>>>>> is that we can use the suffix -m for a mid term build and -x for an
>>>>>> experimental/exploratory build.  That could help reduce confusion about
>>>>>> the purpose of each.  -m is expected to go into the upcoming release.
>>>>>> -x additionally has a developers plans/exploratory-ideas that are
>>>>>> unlikely to be in the upcoming release (preview, of interest to early
>>>>>> adopters, who may want to get involved in helping us refine ideas and
>>>>>> fix issues).
>>>>>>
>>>>>> For 2.2.0 I think we will likely have just an -m, with the MIDI_OUT in
>>>>>> it too.  There will be plenty new in the -m for 'early adopters'.  If
>>>>>> MIDI_OUT is looking unlikely for 2.2.0, then it should be in an -x, but
>>>>>> it being in the -m would be far better.
>>>>>>
>>>>>> --James.
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

Vaughan Johnson-4
In reply to this post by James Crook
On Tue, Apr 18, 2017 at 1:50 AM, James Crook <[hidden email]> wrote:
> I think it is fine/good that we distinguish public betas (which have not
> been through a full QA process) from releases (which have).

Yes. That's what we did when we had betas. Of course , we had a much
less rigorous QA process most of that time.

>
> I am fine with phasing out KTT as a term.  At the moment only we know
> what KTT means.  'kicking the tyres' is neither a good nor reliable
> practice for evaluating a car, motorbike or bicycle.

Good. Thanks.


>
> If we have more than one beta at a time we will need a clear way to
> distinguish the different purposes of those betas.  Gale has made that
> point off list, and I agree.  I think if we plan to have a mid term
> beta, then we need to have a name for it.  If we plan to have an
> experimental beta too then we need a name/designation for it.

As they say, we'll burn that bridge when we come to it. ;-))  Didn't
have that kind of problem for the 12 yrs we released betas, but yep,
it could happen, especially if we get into more ambitious projects
we've discussed.

Thanks,
Vaughan


>
> --James.
>
>
>
>
>
> On 4/18/2017 4:35 AM, Vaughan Johnson wrote:
>> -1 to nonstandard terms like KTT and experimental/auteur and any
>> proliferation of terms with ultra-fine distinctions from "beta".
>>
>> If we return to releasing betas, as we did years ago -- and now in
>> parallel -- I think that's great.
>>
>> - Vaughan
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Terminology (was Accessibility of Spectral Selection Toolbar at high frequencies)

Vaughan Johnson-4
In reply to this post by Stevethefiddle
Steve, no confusion. I'm LOL-ing at your and James's bon mots. Did
have to look up MOT because I was reading sequentially.

Maybe moot, but amusing!

- V

On Tue, Apr 18, 2017 at 4:24 AM, Steve the Fiddle
<[hidden email]> wrote:

> On 18 April 2017 at 12:06, James Crook <[hidden email]> wrote:
>> On 4/18/2017 10:46 AM, Steve the Fiddle wrote:
>>> On 18 April 2017 at 09:50, James Crook <[hidden email]> wrote:
>>>> I think it is fine/good that we distinguish public betas (which have not
>>>> been through a full QA process) from releases (which have).
>>>>
>>>> I am fine with phasing out KTT as a term.  At the moment only we know
>>>> what KTT means.  'kicking the tyres' is neither a good nor reliable
>>>> practice for evaluating a car, motorbike or bicycle.
>>> Very true. More like an MOT would be better :-)
>>
>> :-)
>>
>> And the American 'mot' for MOT is I think is 'smog test'.  So I say
>> Vaughan's point still stands.   And even if we call it a smog-test-build
>> people in europe aren't going to know what it is. 'Mid-term-beta' or
>> 'mid-term-build' probably will do - using 'term' rather than 'release
>> cycle' to be vaguer, since Vaughan has cast doubt on what a 'release
>> cycle' is too.
>
> In case there's confusion, I didn't mean to suggest that we call it an
> "MOT", but that testing of a mid-term beta should be a proper safety
> check of critical parts (like an MOT in the UK), rather than "kicking
> the tyres".
>
> I'm in agreement with what others have said - if we have a mid-term
> beta (and no experimental branch or any other "special" builds), then
> simply call it a "beta".
>
> Steve
>
>>
>> Anyway, the right 'mot' for MOT or whatever is all moot, if we don't
>> actually have one, and whether we have one or not seems a more pressing
>> question.  One thing that came out of an off-list discussion with Gale
>> is that we can use the suffix -m for a mid term build and -x for an
>> experimental/exploratory build.  That could help reduce confusion about
>> the purpose of each.  -m is expected to go into the upcoming release.
>> -x additionally has a developers plans/exploratory-ideas that are
>> unlikely to be in the upcoming release (preview, of interest to early
>> adopters, who may want to get involved in helping us refine ideas and
>> fix issues).
>>
>> For 2.2.0 I think we will likely have just an -m, with the MIDI_OUT in
>> it too.  There will be plenty new in the -m for 'early adopters'.  If
>> MIDI_OUT is looking unlikely for 2.2.0, then it should be in an -x, but
>> it being in the -m would be far better.
>>
>> --James.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
123
Loading...