From kde-core-devel Mon May 10 08:52:17 2004 From: Bo Thorsen Date: Mon, 10 May 2004 08:52:17 +0000 To: kde-core-devel Subject: kdepim release (Was: Re: [Kde-pim] KDE 3.3 Release Plan is up) Message-Id: <200405101052.22598.bo () klaralvdalens-datakonsult ! se> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=108418628200489 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-02=_GL0nAaGxAFTMR6b" --Boundary-02=_GL0nAaGxAFTMR6b Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I will try summing up all the discussion here, and add my own points to=20 it. The kdepim discussion has been focusing too much on the user point of=20 view, but that's not all of it. There are several reasons why staying 3.2=20 compatible is a good idea, and a couple of problems with it. Pros: =2D More stable environment for the developers. This is such an important=20 thing for us pim people, since most of us are only developing in kdepim.=20 It's incredibly annoying to stay on HEAD for something your not focusing=20 on. Someone claimed this is a stability problem for libs, but I fail to=20 see that. If you're on the bleeding edge, sometimes you bleed. But the=20 pim people just want to code the pim apps with less hassle and use the=20 libs. =2D Less upgrading for users. This is *not* a small deal in corporate=20 environments. But people (me somewhat included) who thinks certification=20 processes are borderline stupidity has problems accepting this. Putting=20 on the KDAB hat and thinking as a proko2/kolab2 project manager, this is=20 a great move towards making commercial backing of kdepim possible. =2D As KDE has grown bigger, it has become an increasingly big problem to=20 get it released. Separating the release of kdelibs/base from the rest=20 will do a lot towards making the freeze period smaller and less=20 intrusive. Andras asked, what makes it such a different part than the=20 rest of KDE. Well, it's not. But this move goes towards the same=20 separation as KOffice and KDevelop has. You can see it as a move towards=20 splitting libs/base from the applications. There are more pros for me, but those are IMHO the most important. Cons: =2D Won't be able to use new libs features. Sometimes this is just annoying= ,=20 other times it's a real problem. Especially the fact that KABC and the=20 resource stuff are in libs is a potential problem. New widgets in libs is=20 something that a lot think is extremely cool and something you can't live=20 without. But with the quality of libs, that's just no longer true. We=20 actually do get sleep at night without the latest and greatest widget :-) =2D Releasing KDE as one big thing does have a lot of things going for it.= =20 Users know exactly what fits together and never has a problem figuring=20 out dependencies. Also, from a marketing point of view, this is a much=20 easier message to tell. =2D The i18n release is so far an unsolved problem. I have absolutely no=20 clue how to get this solved for 3.3 :-( =46inally, someone mentioned bugfixing as a an item for the cons - that=20 kdepim won't benefit from the latest bugfixes. That's actually an=20 argument for people being bad at backporting! And the counter argument is=20 of course that kdpeim won't benefit from the latest bugs :-) This=20 argument goes both ways. 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=20 about it, you should keep KOffice and KDevelop in mind - for those the=20 answer would be they use the platform. I believe that after the i18n problem has been solved, the split will be a= =20 great thing. I only see one real problem with it, and that's the point=20 that one big KDE is easier for users to figure out. Everything else is=20 speaking for a split. Bo. =2D-=20 Bo Thorsen | Praestevejen 4 Senior Software Engineer | 5290 Marslev Klar=E4lvdalens Datakonsult | Denmark --Boundary-02=_GL0nAaGxAFTMR6b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQBAn0LGmT99lwfUS5IRAomPAKDd8A/pWDMXA9N11fr9vFSSZ//RBwCfVvDI OlP91Zkr+9y6IU5ZF8CIRUI= =TVKC -----END PGP SIGNATURE----- --Boundary-02=_GL0nAaGxAFTMR6b--