OK, let's move this to the mailing list.
I think that discussion of individual issues in issue comments is maybe
more appropriate - but there's another new factor that is of general
interest.
For the backscene of the specific issue, making "chorus" actually do
what it says,
see https://codeberg.org/sox_ng/sox_ng/issues/276
TR;DR: The "chorus" effect has never worked, giving bizarre output, and
Prof Spock has succeeded in making it do what it says in the manual.
I'm writing here because I'm struggling with another issue: maintaining
four separate release lines:
14.4.3.X: Critical bug fixes to the first micro "bug-fixed" version of
14.4.2
14.5.0.X: Critical bug fixes to the first minor release with new features
14.4.X: Yet more normal bug fixes to 14.4.3 for those timorous of new
features in 14.5.*
14.5.X: Normal bug fixes to what went out as 14.5.0(.*)
oh, then there's 14.6 in the pipeline for May.
Now, I may be unhinged, but I would like to maintain SoX "as one
should". Jus' doin' my best, man.
They say that some people want something as stable as possible with
trusted bug fixes, 14.4.2 fixed,
that others are prepared to risk new code but don't want mega new stuff
that probably doesn't work
and others are not afraid to bleed, so I'm trying to respect those choices.
What does this mean for developers? That:
- if you're fixing a bug, find the branch in which it was first present,
fix against that - on its own personal branch that's importable anywhere
preferably - and I'll merge it (or forward-port where necessary) also
against more recent branches
- If you're implementing a new feature, checkout from the 14.X branch,
make a branch and implement against that.
The specific case, to use an example, is making the "chorus" effect
actually work. I think 14.4.2 could do with this too but I'm not
maintaining that, so 14.4.3, checked out against branch 14.4.X would be
the place to do that to give most productive results.
I'm hoping that git will do the right thing for me in all the dericative
branches but am struggling to understand it and what it can or cannot do.
At present, having followed a single "main" branch, pausing while
release candidates settled down and fixing their most atrocious bugs has
functioned but that's not workable long-term. I just found a critical
bug in 14.5.0 (input file fetched with wget is popened("r" instead of
"rb" on Vindovs) so CRLF in audio files get mangled) that I can't apply
to main because it's moved on too much.
See https://codeberg.org/sox_ng/sox_ng/wiki/Branches for the horrible
reality.
I seem not to be a programmer any more, but trying to devise a system
that allows programmers to interwork productively... me included!
Inducted into management. Gak!
If I'm just manic or off my trolley, do say so. For the moment I'll see
if proceeding thus works better.
All contrasting opinions are most welcome
M
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#41): https://groups.io/g/sox-ng/message/41
Mute This Topic: https://groups.io/mt/110595666/21656
Group Owner: [email protected]
Unsubscribe: https://groups.io/g/sox-ng/leave/13602885/21656/313486934/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
