iPod collection rewrite merge considerations

[Matěj Laitl]

Hi list and mainly Bart,
the iPod collection rewrite that I've been doing since December has reached 
the merge-ready state. It has no known regressions or feature omissions wrt 
the old plugin and fixes at least 6 b.k.o. bugs. It has been working fine for me 
and Santiago (who volunteered to test it) for months on 4 different iPod 
models.

I haven't touched the old plugin and develop the new in a separate 
ipodcollectionnew directory, both plugins are built by default, one of them 
has to be disabled in Amarok config to prevent clashes. This is fine for 
development, but impractical once it is merged. There are several options for 
the merge:

a) just drop ipodcollection in one commit and add ipodcollectionnew in second 
commit. People who have disabled iPod collection plugin will have the new one 
enabled.
b) drop ipodcollection in one commit and add ipodcollectionnew renamed back to 
ipodcollection in second commit. Transparent to user.
c) drop ipodcollection and add ipodcollectionnew renamed back to 
ipodcollection in one big commit. I'm against this because the old and new one 
have nothing in common and the diff will look horrible.

Some bugs will for sure pop up, but I'm confident in the general code design so 
it should be nothing major. The only big TODO is podcast support, bat that's 
not a regression. I'm prepared to maintain the code long-term. Another 
question is whether it makes sense to run it through reviewborad, I think that 
rather not (it's too big), but I'd still be glad if someone other would read 
the code before or after merge [1].

[1] 
http://quickgit.kde.org/index.php?p=clones%2Famarok%2Flaitl%2Famarok.git&a=shortlog&h=refs/heads/ipod-
rewrite

Regards,
			Matěj