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, [email protected] 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. _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
