It's becoming clear to me that we need to distinguish between the
different aspects of FLAC software, whether it be the core library,
command-line, or third-party tools.
Although I use the command-line tool exclusively (plus a few of my
own tools), I really don't care about bugs there or missing
features. Maybe I'm being selfish, since my bugs fixes and
significant design suggestions have all been implemented in the
official release, so I'm kinda done with the need for change.
Where my concern is focused is the core library. There I have
experienced no bugs at all, and I've recorded hundreds of live
musical performances that were either originally created as FLAC
(SD702) or compressed to FLAC before archival.
The third-party front ends tend to distribute old versions of the
command line, and what's most important is that the third-party tools
were never maintained by Josh.
Glancing at the bug database, it would be helpful if the open bugs
could be classified, particularly if, as I suspect, many of them
would end up with an official status of "will not fix" or "by
design."
Finally, I also consider porting efforts to be separate. So, if
Windows support is the only place where compile errors and bugs are
appearing, then it would make more sense to me if there was a Windows
porting project that is distinct from the official FLAC distribution.
Brian
On Nov 21, 2011, at 08:39, Declan Kelly wrote:> On Wed, Nov 16, 2011 at 03:36:12PM -0800, brianw at sounds.wa.com wrote:
>> As a seasoned software developer, I've learned the hard
>> way that every single change to a source code repository is a chance
>> for a new or old bug to appear. I am not aware of any bugs in FLAC,
>> so the lack of changes is perfect.
>
> The only bug I'm aware of is the end-of-line one, where the command-
> line
> utility's output goes one character further than it should,
> resulting in
> extra scrolling when the output is too long for the console.
> Anyone using a FLAC front-end will not even be aware of that, and I am
> guessing that most possible fixes might break any of the existing
> front
> end tools that depend on this behaviour.