Moving KDevelop4 from trunk/KDE/ to trunk/extragear/sdk

[Andreas Pakulat]

On 01.10.07 14:55:32, Alexander Dymo wrote:
> On Monday 01 October 2007 14:25, Andreas Pakulat wrote:
> > The only downside: I and probably the rest of you as well, have no idea
> > how translations are handled in that case...
> 
> I think that moving kdevelop4 to extragear reduces KDevelop visibility for 
> users and lowers KDevelop's status inside KDE project (no that it's too high 
> now ;) ). I can't see any technical reason to not move, in fact it would be 
> more convenient for us. But I'm not sure that our convenience is worth 
> loosing status of "official KDE project".

I completely disagree. Being in keg hasn't been a problem for some of
the major KDE apps, like amarok or k3b. None of them suffered from being
in k3b and keg in KDE4 is an _official_ part of the release, we're going
to get a KDevelop release with any KDE 4.x release we want, without any
extra overhead, except creating a tag before the KDE4.x tagging.

I'm not talking about playground here!

> > PS: KDevPlatform would stay inside KDE/trunk as its used by quanta in
> > kdewebdev...
> 
> Ok, and how that would help us. We still won't be able to release the platform 
> as frequently as we want and we still won't be able to break KDE freezes for 
> it. And platform is not just a collection of stable interfaces, it's 
> basically our application (shell)

Shoudln't shell also keep BC? So thats just part of the stable
interfaces as well.

> and several major plugins. So IMHO we'd need to move all kdevplatform
> + kdevelop + kdewebdev altogether from trunk/kde.

Maybe thats even preferable, seeing that platform is still young and may
have to mature more during the 4.x lifetime which means more releases
that KDE does...

> PS: these all release problems are not KDevelop problems but i18n 
> infrastructure problems so instead of moving our source I think we should 
> rather focus on i18n infrastructure.

No, its not just i18n problems, its also problems of having to follow a
schedule that we might not really fit into (or don't want to follow).

Apart from that I don't see how i18n issues could be fixed, except by
providing individual i18n packages for each module in trunk/KDE. But
that option is AFAIK not going to happen (or at least thats how I
understood Stephan).

Andreas

-- 
Many changes of mind and mood; do not hesitate too long.