kdepim release (Was: Re: [Kde-pim] KDE 3.3 Release Plan is up)
Olivier Goffart
ogoffart at tiscalinet.be
Mon May 10 14:34:48 BST 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le Lundi 10 Mai 2004 08:52, Bo Thorsen a écrit :
> I will try summing up all the discussion here, and add my own points to
> it. The kdepim discussion has been focusing too much on the user point of
> view, but that's not all of it. There are several reasons why staying 3.2
> compatible is a good idea, and a couple of problems with it.
>
> Pros:
>
> - More stable environment for the developers. [...]
(and i'll add for testers users)
This is the main point, and is only true until the next version of KDE is
released.
We keep the KDE 3.2 compatibility only for that reason.
But until KDE 3.3 will be released, we will drop it.
> - Less upgrading for users. [...]
that's not an issue.
for example, urpmi kdepim will install kdelibs for free :-)
> - As KDE has grown bigger, it has become an increasingly big problem to
> get it released. Separating the release of kdelibs/base from the rest
> will do a lot towards making the freeze period smaller and less
> intrusive.
KDE is a desktop environement, it make sens to release all in the same time.
Having only one release plan is simpler than having a release plan for
kdelibs / kdepim / kdenetwork / kdemultimedia / ... separately.
and even with that, everybody will split every package in apps.
> Cons:
>
> - Won't be able to use new libs features. [...]
Remember than often you can #ifdef or even add some class to a compat dir.
It's complicated to maintain, but that's the deal.
> - Releasing KDE as one big thing does have a lot of things going for it.
> Users know exactly what fits together and never has a problem figuring
> out dependencies. Also, from a marketing point of view, this is a much
> easier message to tell.
Yes, this is IMO the main important Cons
> - The i18n release is so far an unsolved problem. I have absolutely no
> clue how to get this solved for 3.3 :-(
For solving it you probably will have to split this package by modules.
That will make a huge number of new package, and will be realy difficult to
package/install.
Is't precisely the easy of install you want to improve?
> Finally, someone mentioned bugfixing as a an item for the cons - that
> kdepim won't benefit from the latest bugfixes. [...]
Not realy important since if the user wants to see the bug fixed, it just has
to upgrade kdelibs.
Keeping the KDE 3.2 compatibility is fine in the developpement cycle, but is
not interesting when kdelibs is released.
Trying to release kdepim and the rest of kde shouldn't be so contrainous.
> I believe the whole argument can be boiled down to one single question:
>
> Is kdepim part of KDE or does it use KDE as a platform?
>
> In this question, "part of" is of course a bit undefined. When you think
> about it, you should keep KOffice and KDevelop in mind - for those the
> answer would be they use the platform.
My question is why aren't KOffice and KDevelop a part of kde.
It seems than KDevelop is already aligned to the KDE release plan.
and KOffice is maybe not mature enough, like apps in kdeextragear.
See how Quanta has just been included in a kde module.
Every applications want to be included in the kde release, excepted kdepim.
> I believe that after the i18n problem has been solved, the split will be a
> great thing. I only see one real problem with it, and that's the point
> that one big KDE is easier for users to figure out. Everything else is
> speaking for a split.
Why? Because the kdepim team think they can't respect the kde timeframe?
We can't force you to be included in kde. but it's a force for both kde and
kdepim to be released in the same time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAn4T+z58lY8jWrL0RAsC1AJ48168UBuWeQu68KVFBwxxobU0qTgCaApCu
Vd0UX19dlp0KkFnmAq2mcE4=
=sUg1
-----END PGP SIGNATURE-----
More information about the kde-core-devel
mailing list