ATF safety

[Paul Cifarelli]

Some of the devs were recently having a discussion on irc about ATF.

The general consensus is that we think ATF is an important feature - one
that will be extremely useful to many of our users.  However, there are
a few risks that concern us.

Because ATF modifies your music files, and does so en mas, it must be
absolutely rock solid before it is released to the general amarok user
community.  Recently an unfortunate (but not at all obvious) bug
resulted in some corrupted music files.  This occurred when only some of
our beta users have enabled it.  The source of this particular problem
has been now isolated and we believe fixed, but we have some concern
that when this is released in a stable release (for example, 1.4.2),
many more users may adopt it, and this may expose yet unforeseen issues
in the implementation.

As  we recognize that our user population is quite large, and we
consider corruption of their music files to be most heinous, we are
considering that perhaps we should proceed with a bit more caution. 
Several of the devs are proposing that ATF be disabled for the upcoming
release, or at least hidden - so that some of our more intrepid users
can continue to exercise it and expose any additional problems, while
protecting the majority of our user base from potential corruption. 
It's not that we think there are any outstanding problems at present -
what we are concerned about is the unknown.


Thoughts?  Comments?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3323 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.kde.org/pipermail/amarok/attachments/20060816/ac63b8f0/attachment.bin>