obsolete templates

Friedrich W. H. Kossebau kossebau at kde.org
Thu Mar 8 13:46:35 CET 2007

Am Donnerstag, 8. März 2007 13:08, schrieb Stephan Kulow:
> Am Donnerstag 08 März 2007 schrieb Friedrich W. H. Kossebau:
> > So, good enough?
> We wanted to avoid this explicitly

Oha. Why? Is there a reference one can read to follow the decision?

The only one I found was a thread on ml kde-extra-gear started by Helio from 
last november:
where he proposed the same.

The arguments (against the proposal) by the commenting keg developers were 
a) trunk is where most activity is, not KDE 3 or 4
b) translators only care for trunk
c) already have a kde 4 branch in another place

I personally do not think these are too heavy arguments.
To a): This all depends on the developers and is just a coincidence, not a 
forcing reason.
To b): Do they really? E.g. Mailody and my former Contacts stuff have no 
problem into getting quite some translations, even only being in playground. 
And kde-pim in branches/KDE/3.5 would have some problems, too, with all the 
new strings for 3.5.7
To c): We use subversion. A coordinated svn switch should do it.

> - and we had a playground in work/kde4 
> before. And the playgrounds and extragears do not really collide - beside
> the desktop files.

They collide also for anyone not too familiar with the structure of our 
repository, like external people writing patches, packagers and translators.
Where is the KDE 4 version of a given program, where the KDE 3 one?

Wouldn't it really be a good solution to reflect the versions/dependencies in 
the directory structure? It would also help to keep the codebase tidy. So 
there won't be any rotting programs in trunk that never got ported to KDE 4, 
only those where people at least started.

Right now it really is a mess IMHO. Also look at the tree below 
http://websvn.kde.org/branches/ and think about the next few years. Will this 

Yes, it would be some work now. But it might save a lot for all of us in the 
future, no? Please think about that.


PS: no need to CC: me :)

More information about the release-team mailing list