RFC: Amarok 2.0 deadline September, 1

Harald Sitter sitter.harald at gmail.com
Thu Jun 12 15:31:49 CEST 2008


On Thu, Jun 12, 2008 at 3:23 PM, Mark Kretschmann <kretschmann at kde.org> wrote:
> Trunk should always be where the main focus is on, and so I'd suggest
> doing it the other way around: Let the SoCers work in (git?) branches,
> while trunk is being shaped into 2.0.

Agreed.

>>  B: that feature freeze is in the beginning of July! This will give us
>>  just under 2 months to get this beast stable.
>
> Yep. We don't have to be anal about it (common sense first!), but I
> agree that we should definitely start focusing on bug fixing. But if
> someone adds this or that small feature after the freeze, nobody is
> going to make a big fuss about it.

I certainly will, if you really want to push it out until september,
everyone needs to focus on bugfixing and not implementing new
features. So instead of freezing, IMO we should compile a list of
features that need to get it, assign it to someone and only those
features will get in.

As for the general proposal:
I think it's not enough time, and defenitely too few releases to
obtain enough testing (especially since we need high profile testing
for the windows and mac deployments as well). And there _are_ missing
important features. Btw, does the media device stuff work?

We need to provide kickass quality as 2.0 is supposed to get uber
press coverage, which makes this realease not only more important than
any Linux-only release, but also most critical to the sucess of
entering two new markets.

I want to note for the Kubuntu inclusion reasoning, that I, as Kubuntu
developer, I will not support making 2.0 default player in Kubunu
Intrepid, if the quality doesn't messures up to 1.4.9.1. While it
would be a shame to have Amarok 1 look outdated in a KDE 4
environment, it would be an even greater shame to deploy an Amarok
that doesn't messsure up to 1.4 concerning most features and
concerning stability.


More information about the Amarok-devel mailing list