Idea for the porting

[Myriam Schweingruber]

Hi all,

On Sun, Aug 30, 2015 at 11:57 AM, Olivier Churlaud <olivier at churlaud.com> wrote:
> Le 30/08/2015 02:07, Stefan Derkits a écrit :
>>
>> Hi,
>>
>> On 2015-08-30 00:47, Olivier Churlaud wrote:
>>>
>>> I tried to do this just to show you how it could be but it doesn't seem
>>> to be doable: everything is too connected...
>>
>> I tried it to and seems good atm, see
>> http://commits.kde.org/amarok/1f01a5c9cbb1dc841004a800a2ce41353d049c80
>>
>> I disabled: services, context, every collection except sql, importers
>>
> Maybe we should (when the porting is done) review the cmakelists to disable
> more easily the plugins. So that we could more easily compile just the core
> or the core +... and so on.
>
> I've seen that we already have it for Playground, Ipod and 2(?) others but
> we might be able to do it in a more thorough way.

Makes sense, but: Playground is not something that is shipped with
Amarok by default, and the iPod stuff is separated due to the non-free
nature of the iPods, and due to historical reasons, at some point the
distributions wanted it to be not integrated by default (Debian IIRC).
But yes, more modularity is a good idea overall.

In that spirit: please all read the mail sent by the icon developer to
this ML a few weeks ago and try to work with him during the port, to
avoid having to do things all over again because we didn't change the
hard-coding of the icons.

>
> @Mamarok: Rishabh and Aditya will join us in a few days I think, since they
> begin to have it compiled in the same way as we do. Are they in this ML? if
> not, can you add them or have them registering?

They are already subscribed
>
> @Mamarok: because of your disagreement the other day with Stefan, please
> take some time to answer on this thread if it seems ok for you too (or if
> you don't care the way we do it, if everything is done at some point :D)

Building core as a first target sounds like a good idea, as it allows
to the split the porting work more easily over several contributors.
But what is something really important are unit tests, those really
need to be written in parallel, writing them afterwards is not exactly
in the spirit of agile development and continuous integration, it is
also a very tedious job to do if those are pushed to after the port.
We have already gone through that path with a lot of pain when we
introduced the unit tests a few years ago.

My disagreement with Stefan was simply due to his "Kill it!" orders in
the devel channel for several core features of Amarok, something
which, coming from somebody barely involved in Amarok in the last
years, is a very bold and unacceptable statement. Removing whole
sections of Amarok like podcasts or dynamic playlists is an absolute
no-go, just because one developer doesn't need it for his use.

Just for the record: Amarok is not and never will be part of the
default packages shipped by KDE, as it is not meant to and never was
meant to be a simple player. We have a very specific user base that
counts on the great variety of features, which makes Amarok rather
complex and not the first choice just for playing the occasional mp3.
Our users need a reliable database as they have huge collections,
working integration of external collections as most keep their music
on remote partitions and/or servers, saved playlists and external
media support are equally important, we have many listeners of
classical music who use Amarok at home combined with their external
sound systems and a vast user base of the podcast and dynamic playlist
features. The Context View is one of the core features as well,
commenting it out for the moment is OK as it needs to be rewritten in
QML anyway, but removing it is out of the question.

It is obvious we do not suit all use cases of music listeners, and we
never meant to, that is normal and people have the choice to use what
they want. That is after all the power of Free Software: giving users
the choice.

Regards, Myriam

-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)