ATF safety

[Jeff Mitchell]

This discussion doesn't need to take place.  As much as I hate saying it (and 
I really hate saying it) we need to disable ATF for 1.4.2 because of MP3 
issues (although Oggs should theoretically be fine once I finish my fixes, 
but realistically most people are using MP3s anyways, and FLACs are still not 
good to go yet) because there are a couple taglib ( 
http://bugs.kde.org/show_bug.cgi?id=132191 ) bugs ( 
http://bugs.kde.org/show_bug.cgi?id=132296 ) that need to be fixed...some of 
which are already fixed in TagLib SVN, some of which may or may not be but 
are expected to be fixed before 1.5 (since wheels usually closes all open 
reports before a release).  These only affect the metadata, not the song 
data, but having that get screwed up is quite annoying, and is much more 
likely to happen in a mass-tagging scenario than otherwise (because these 
bugs can, do and will affect anything using TagLib 1.4, including prior 
versions of Amarok and the upcoming 1.4.2).

Since we announced it in 1.4.1 as beta, I think it would be beneficial to make 
a remark about it so that users don't think it just disappeared, 
i.e. "pending release of an associated library and will appear in 1.4.3" or 
some such thing.  But -- and it breaks my heart to say it :-) -- we should 
hold off for 1.4.3.

It is turned off by default.  Probably I should remove (or could just disable) 
the GUI elements for turning it on for 1.4.2; then, once it is released, add 
them back in to SVN so people can keep testing.  Disabling has the advantage 
of having the information there, but not allowing users to turn it on; but 
that's not too intuitive.  And also, if anyone running 1.4.2 wants to help 
test, they can be told how to enable it manually.

--Jeff




On Wednesday 16 August 2006 22:31, Greg Meyer wrote:
> On Wednesday 16 August 2006 10:10 pm, Paul Cifarelli wrote:
> > what we are concerned about is the unknown.
> >
> > Thoughts?  Comments?
>
> I'll chime in here as a beta tester.  I have been very hesitant to turn atf
> on for exactly the reason that it modifies all the files in the collection
> (en masse and in an irreversible way) and despite Jeff's insistence on its
> safety, I don't trust such a pervasive feature until it has been tested
> more extensively.
>
> Of course, as an aggressive user, I have often jumped into new features and
> paid dearly for it (e.g. losing 18 months of stats) but in this case we
> aren't talking about a database, but with the data itself, and I don't feel
> like re-ripping my whole collection of cd's.
>
> I'm not sure what all this means.  I guess I am arguing for a cautious 
> approach for our users.  Any risk of destroying their collections is
> something to be avoided at all costs imho.