On Thursday 05 June 2008, Ana Guerrero wrote:
> Hi folks,
> We have been delaying taking a decision about this for too much time now,
> the freeze is coming up , and we need to have it clear, for our users,
> the release team and the rest of Debian.
True. We need to have it clear.
> Basically we can ship either KDE 3.5.9 or KDE 4.1. For some people in the
> team it seems clear we should ship KDE 4.1, for some other it is clear we
> should ship KDE 3.5.9. The latter is my opinion, so here you have a mail
> explaining why we should release with 3.5.9. Feel free to reply with a nice
> mail of why we should ship with KDE 4.1, detailing as well how much time
> *you* are planning to invest in this goal.
> By the way, my proposal is shipping KDE 3.5.9 with the KDE 4.1 development
> platform: kde4libs, kdepimlibs and kdebase-runtime.
My expected times:
- Kde3 as desktop: 0. Maybe instead working on getting interesting kde4 apps
available in lenny. or maybe I will just focus on kde4 wherever that is.
- Kde4 as desktop: what it takes. Lots. but 15-25 h weekly should definately
be possible. Except week 31.
- and I have no kde3 desktops around any more to test and work with.
My proposal is to ship kde4.1 with kde3libs and kcontrol and kios from kdebase
(I am currently working on stripping down kdebase)
- Huge advantage with kde4
Active upstream development, bugfixings and general work. Kde3 is dead.
Nothing in e.g. khtml will be fixed if it doesn't work (I encountered many
really major like google front page)
Kde4 shows new ways of thingking the desktop which I feel is really
interesting and worth to be spreading out as soon as possible.
Kde4 is new and interesting and the right way to go. And a real improvement to
debian and debian's reputation of shipping ancient software.
> - KDE 4.1 has not been released yet.
> KDE 4.1 has not been released yet, looking at the release schedule , it
> is supposed to be released July 29th, this is already impossible with
> current Lenny's release, and we would need an exception from the release
> team that will be only granted if it is really worth it. Then, a delay in
> this schedule from KDE release team would be bad for us, since we are so
> tight in time. The sooner we could upload something to unstable would be
> with the RC1 that will be released on the 15th of July, 2 weeks before the
> final version. Lenny is supposed to go into full freeze in the mid of July,
> this could be delayed, but what is sure libraries will be frozen in 3-4
> weeks, and we need ship a huge amount of new libraries.
> Besides, it is usually better ship an update of 4.1.x that contains fixes
> to the most important problems found in the 4.1.0 release.
I expect kde4.1 to be on time - but I actually think it is worth to delay
lenny for if needed.
> -Build dependencies we need to take care of
> And then, it is not only the KDE 4 desktop, there are a set of build
> dependencies we have to maintain and not all of them are already in
> unstable, those dependencies are: akonadi, automoc (already in unstable,
> but it is a snapshot), decibel, soprano, tapioca-qt and telepathy-qt.
> And we'll have soon phonon, but I do consider phonon part of KDE 4. We'll
> need to ship it anyway in order of upload the development platform to
I don't see any issues here but waving red herrings around.
But I don't know if anything actually uses decibel, which we then could ignore
and with that tapioca and telepathy.
> -Some widely used apps of the KDE desktop are not ready
> Even if they are not shipped with the core packages, some apps belong to
> the KDE desktop and to the KDE project. We have here Koffice, kdevelop or
> amarok. I have not idea of the exact status of amarok, but I think it won't
> be ready. Amarok is one of a lot of widely used apps in the KDE desktop
> that won't have a substitute in KDE 4. There is a myriad of small apps in
> this situation.
Amarok, true. kdevelop, true, but we have the kde3 versions.
And koffice - to be blunt and honest - kde3 koffice actually sucks.
> Koffice 2 won't be ready so we are shipping with koffice 1 that needs some
> parts of KDE 3 to work properly (like kcontrol), so it will need some
> hacking because it is not currently fully installable in KDE 4... and it
> won't be properly integrated anyway. I'm not sure how well works kdevelop
> with KDE 4, but newer kdevelop (that needs now kdevplatform package) won't
> be ready. Quanta needs as well kdevplatform, but quanta is shipped inside
> kdewebdev and it is one of the modules we have not packaged yet (together
> with accessibility and bindings).
We can keep kdevelop and webdev from kde3 no big issue. And the kcontrol issue
I already have on my radar.
There is also other kde3 apps we need to keep around:
> Then you have that some interesting apps usually distributed in the core
> modules, are not yet ready, for example kpilot in kdepim. AFAIK, this is
> postponed for KDE 4.2.
kpilot is utterly unimportant. it only works for very few devices anyway, and
most of these are decommisioned already.
> -No positive feedback about shipping it
> My blog post about how to install KDE 4.1 beta 1 had some feedback of other
> developers in planet and specially from users in several blogs and forums
> that linked my post. Most of the people seem to like it as in "it will be
> cool", but everybody seems to agree that it is not still a replacement
> for KDE 3 in their daily tasks.
> Basically, I see 3 kinds of users: developers, power users and average
> users. KDE 4.1 could be ready for developers who are able to cope with
> the lack of some apps, mixing kde3 and kde4 without risks etc, and
> the same goes to power users. But I do not see it ready for final users,
> they won't like this (imposed) change.
> We would be shipping the KDE 4.1 desktop just released, and usually in the
> community, average users wait until more advanced users are used to this
> new software then it is when they adopt it, because then, they have support
> and help from forum and mailing lists from this more advanced users.
> With the current beta power users and developers still do not see it ready
> for daily use, so what you can expect for our average users.
eh ? People won't adopt it before it is very easy available - and we
shouldn't push it until it is adopted. It is a kind of chicken-egg issue
described here - and we need to bring the chickens.
And people can't tell if it will be usable for their daily tasks when only
have tried it for a hour. It is new and different and people needs to adapt to
something being different.
> -Some arches do not like KDE 4
> Let's keep this short: KDE 4 needs to be built in all the release archs,
> and it actually does not.
It is only hppa. It should be possible to get someone to fix it.
(and it isn't autobuild on arm* platforms, but I have pretty good faith in
that it builds there - and most possible build failures on arm* are related to
qreal vs double, so easy fixable)
> -You can have everybody happy
> My proposal is release with "old" reliable KDE 3.5.9 not forcing anyone
> to update to KDE 4.1, and just provide 4.1.x "official" backports. So whose
> who want to use KDE 4.1 will just use the backports and besides, these
> users will have these backports updated through the KDE 4.1.x (x=1,2,3..)
> updates. I am willing to work on these backports.
> By the way, Backports infrastructure is only for stuff in testing, but I'm
> sure we can find a nice solution here.
We might not be able to have everybody happy, true. Then we have to choose.
I choose to make kde4 people happy. And backports isn't a real solution.
> I have been thinking this way since months ago,
This is where I am about drop the part about "being nice" in the email, but I
guess I won't write anything further.
> but I did not want to kill
> people's hope of shipping it in Lenny without looking at KDE 4.1 evolutions
> in development and really seeing whether it fits in our calendar with
> respect to Lenny. And with the current data, I think it is clearly a bad
> idea shipping KDE 4.1.
I think it is clearly a very good idea to ship kde4.1.
Not doing so will be a very big mistake. And it fits exactly in the schedule
Do you know how to get access over the 24-bit proxy from Netscape 4.8?
The point is that you neither can debug a GPU, nor must rename a driver to
forward to the IDE mousepad.