a road map for 2.0

[Gábor Lehel]

[long mail; sorry]

On 6/10/06, Ian Monroe <ian at monroe.nu> wrote:
> I posted a possible road map for development over the next ~year on
> the wiki. Basically I was just putting together ideas we talked about
> at K3M and in IRC.
>
> Its at:
> http://amarok.kde.org/amarokwiki/index.php/Road_map_for_2.0
> Devs should feel free to expand on the road map or add alternatives.
>
> And for those that can't be arsed to open the wiki:
>
> One possible road map for 2.0:
> *Work continues on 1.4 in trunk. People who want to can work on
> Gabór's 2.0 branch.
> *At about 1.4.4, trunk is copied into a seperate branch. The Qt 3 to
> Qt 4 scripts are run on trunk and it is made into a compilable state.
> *Make trunk somewhat functional with Qt 4 and kdelibs4, copying in
> work from the Gabór's 2.0 branch (such as ThreadWeaver and
> Multitabbar)

This is one way. The other way is the one I outlined in my reply to
the 'Reminder: commit major changes...' thread, which I think is
better. Remember it took basically all of K3M just to run the qt3to4
script and get it compiling, so I think it would be less work to port
the changes from 1.4 to 2.0, than vice versa.

For reference, I'll paste my reply there, here:

"I think the plan now should be to get amaroK2 (based on whatever
version it was forked off from) working as perfectly as possible,
fixing crashes, etc. This way it's much easier to track regressions
when we merge, than "it was broken before, it's even more broken now,
I wonder what broke it?". Q3* compatibility things probably shouldn't
be replaced, except where it's necessary to make things work, to make
merging easier. Once it's all working reasonably well, do a mass-merge
of everything that has changed in trunk, probably by hand, and get it
working as well as it was before -- seeing as it's less code, this
should be less work than the original port was. Then merge everything
that changed while doing the previous merge, which should be even less
work, and so on, until the two are synced. (This is like the strategy
the KHTML guys used to port to Safari's JSCore). Ideally, the merging
and the moving of amaroK2 to trunk should be somehow synchronized,
either by delaying the merge or by bringing the trunking forward."


To be clear: What we do *not* want is to have heavy development
(redesigns and refactorings) going on in both 1.4 and 2.0 at the time
same, because that really will be merging hell. If we want to start
doing exciting things in 2.0, we have to stop doing them in 1.4.
(basically, halt development except for bugfixes)


> *Remove KDE dependencies. Doing so will allow the #amarok crowd to
> continue testing SVN trunk (the kdelibs4 dep would stop most of them
> probably) and give us a solid base to develop from and on multiple
> platforms. The output of kconfig_compiler could be commited to SVN or
> made part of the tarball creation process. We might have to hand code
> some stuff to emulate KConfigXT still during this interm period.


I'm not convinced this is a good idea, or that it's an especially easy
thing to do. Amarok has been a KDE application from its very
inception, and KDE classes, idioms, and designs likely permete every
bit of it. In short, I expect it would be a hell of a lot of work;
even more than porting from Qt/KDE3 to 4 was/is. And I'm not very
inclined to work on it myself; there's plenty of more useful things to
be doing.

What would the benefits be?

- #amarok people can keep up with trunk easier -- the benefits of
this, are, I assume, more testing.
Given progress so far, I expect that we will have enough immediately
visible problems to keep ourselves occupied, without needing another
few dozen eyes; when we get to the point where we can start beta
testing, KDE4 will probably have settled down a bit as well.
Also, a kde4 environment isn't that hard to set up, if you know how to
do it; we (I) could provide detailed instructions on the wiki (this
would come in helpful for the devs too, anyways), so it's certainly
possible for the #amarok crew to keep up, if they want to. The issue
would more be the breakage after new kdelibs snapshots; see next.

- We could work against a stable API, rather than an evolving kdelibs.
If one were starting a new application from scratch, this would
certainly be a very good argument, but that's not our situation. I
think the work needed to port everything away from kdelibs, and then
*back again* once it's solidified, would outweigh the incremental
changes we'd need per snapshot many, many times over. (We could also
employ a strategy used by kdebase for example, where in preparation
for a new snapshot, someone ports his/her local copy over (or multiple
people do it in a branch), and then commits it once the snapshot
arrives; this way the amount of 'downtime' can be minimized).

- We could port to Windows sooner.
I don't know if this is really wanted, we only have to get it working
by the time we release; and given that just keeping up with kdelibs
will give us most of this "for free" (if it doesn't already), I don't
see the point in expending a ton of effort to port away from it.

- We could release before KDE4 does.
This is an interesting question, given that no one has a reasonable
clue when either amarok2 or kde4 is going to be in a state to release
:-). There's two possibilities; either we end up wanting to release
concurrently with or after KDE4, in which case there's no problem at
all; or we end up wanting to release before it. I don't know what the
probability of the second one happening is. In any case, I don't think
we should take such a drastic measure against something which may not
even happen at all; especially since if it does happen, and we decide
it's worth it, we could just do the Qt-port later, when it becomes
clear that it will happen. Thoughts?


> ===Woohoo, 2.0===
> :*Refactor CollectionDB, Playlist and the Engine to create the
> well-designed "core."

An aside, anyone have some concrete ideas about this? All I've really
heard so far is "things are designed horribly now, so redesign them
for awesome++, and maybe make the collectiondb more central". What
specifically sucks about the current design, and how would you fix it?

Some things are a given, like Phonon, Solid, and porting *ListVIew
based things to a Model/View design, and maybe also porting
CollectionDB to QtSql, or perhaps ThreadWeaver to Mirko's Qt4 version;
but beyond those, what else?
Anything not involving "port X from Y to Z"? ;)

I'll add mine:

- Moving MetaBundle from a single class for every type of file, to an
abstract base class and subclasses for each type.

> :*Add nifty features that take advantage of the core. Consult usabilty experts.
> :*A Phonon engine with a KDE4 dependency could be created at this
> point. Actually any of the plugins could continue to depend KDE.
> :*Perhaps have some Qt-only beta releases.
> *As KDE 4 matures, re-add the KDE dependency. Take advantage of Solid etc.
> *Amarok 2.0 tarballs are given to distros along with the KDE 4
> tarballs and it is officially launched the same day as KDE 4.


-- 
Work is punishment for failing to procrastinate effectively.