Reminder: commit major changes to branches/work/kde4 in addition to /trunk

[Gábor Lehel]

On 6/4/06, Dan Meltzer <hydrogen at notyetimplemented.com> wrote:
> Hello,
>
> I've been playing around with the kde4 port, and while I don't expect it to
> work, I did notice that a lot of the major recent changes since the split
> were not committed to both, the major one I'm thinking of is moodbar being
> deleted.
>
> It seems like it would make sense to commit them at the same time, and keep
> the code-base fairly similar, in order to make it easier in the future to do
> porting.


The problem is it's not as simple as an `svn merge`, because in many
cases the new code has to be ported to new APIs as well.

My plan with the port was basically 'no plan' -- start porting things,
and figure the rest out later. (the reason I started wasn't because
it's logical, or because now is the right time, or anything -- rather
because I felt like doing it, and didn't feel like working on trunk;
and I had to do *something* productive during the k3m. the #1 goal of
the amarok project is, after all, to keep its developers entertained).

Since now is more or less later...

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.

anyway, eean says he's posted a roadmap, so i'll go look at that now.
(after i get through the other 6 days of mail before it.)

-- 
Work is punishment for failing to procrastinate effectively.