From kde-core-devel Mon Jul 28 16:26:03 2003 From: Marc Mutz Date: Mon, 28 Jul 2003 16:26:03 +0000 To: kde-core-devel Subject: Re: Qt 3.2 requirement X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105947590731815 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-02=_26UJ/oE7avyux/F" --Boundary-02=_26UJ/oE7avyux/F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi! Prologue: KDE has a nice track-record of doing things "because they were always=20 done this way". This is again one of those issues where this shows up. KDE - it is said - is all about pragmatism. However, recently it's more=20 about religiously fighting for principles even when they start hurting=20 the project. This thread is one example. The STL debate was another=20 one, and I expect the no-GPL-in-kdelibs to be forthcoming. On Friday 25 July 2003 23:56, Martijn Klingens wrote: > On Friday 25 July 2003 19:47, Ralf Nolden wrote: > > I ack coolo that supporting two versions is a pain. > Since Kopete has standalone releases that have to compile against > other KDE/Qt versions I can confirm from personal experience that > maintaining compatibility across multiple versions is a pain if you > also want to use the newest stuff where it's available (or are used > to it and forget it wasn't in the old version). This pain is self-made. It stems from violating the layering Qt<-KDElibs<-apps Qt/kdelibs layering is e.g. violated where (as Matthias detailed)=20 kdelibs subclasses try to fix bugs in Qt instead of fixing Qt in the=20 first place or maintaining a layer between Qt and kdelibs (the famous=20 qt-addons) that is bound to a specific Qt version. Similarly, apps/kdelibs layering is violated where e.g. apps try to work=20 around bugs in kdelibs or Qt w/o #ifdef'ing the workaround to a=20 particular Qt/kdelibs version. The latter would force a re-evaluation=20 of the workaround for every new release, guaranteeing that workarounds=20 drop out of the code as their causes are fixed upstream. As it is now,=20 however, KMail (as an example) is full of workarounds for bugs or=20 missing functionality in Qt/kdelibs that no-one understands anymore. I=20 don't expect other subprojects to be much better in this regard. Layering would automatically be maintained more accurately if KDE=20 adopted the policy of only requiring the latest stable release=20 branch's .0 version. Bug fixing in the libs is great, but using this as=20 an argument for requiring the new libs is nonsense. If people are being=20 bitten by bugs that are fixed in an upstream release, then they have=20 incentive enough to update. OTOH, people who don't experience those=20 bugs won't want to update, b/c - like it or not - updates are always a=20 risk for a production system. > For Kopete it's something we'll have to live with, but for KDE in > general I'd strongly recommend AGAINST maintaining 3.1 compatibility. You should ask yourself what that pain consists of. I strongly suspect=20 that it's inter-version differences of the upstream libs. If that is=20 so, KDE - lacking serious regression testing - very much benefits from=20 apps like KOffice or Kopete that want to maintain compat with at least=20 the last stable Qt/KDE release. It's frequently such projects that=20 point out incompatible (be it BIC or behavioural) changes in kdelibs/ Qt, whereas the rest just accepts them with a recompile and a fix. > I encourage anyone who disagrees to try maintaining compat for a > fairly big application for a few months and then tell about the > experiences. I'm pretty confident all of you would instantly agree > with Coolo and Ralf by then! :) The most important pain you have with keeping backwards compat for a=20 subproject is that people try to bash you for doing so and don't have=20 anything better to do than implement a new feature in kdelibs and run=20 around all of CVS porting apps to use that new feature - without=20 #ifdefs. The std argument of course being "I'm too lazy to test my stuff and want=20 others to perform this painful task for me". Of course, they don't say=20 so. But look around this thread. All you'll see as arguments for=20 requiring Qt 3.2 for CVS HEAD is paraphrased and euphemism-ized "I=20 don't want to write tests for my new feature. I want others to play the=20 guinea pig", sometimes paired with "I don't want to backport my bug=20 fixes. I consider KDE 3.2 a bugfix release. Who on earth still uses KDE=20 3.1.x?". I'm sorry if the above sounds harsh, but it's the essence of the KDE=20 development model if you look at it from outside it's ivory tower. The running after people commiting dependencies on later libs in your=20 code without asking for permission is the real pain you have when you=20 maintain a project for two different KDE versions. The issues you get=20 when upgrading to a new Qt or kdelibs version are for the vast amount=20 of cases self-made: You've relied on undocumented or not properly=20 documented behaviour (ie. you looked at the source instead of at the=20 docs). That is fixed with a quick patch and then done, whereas the=20 introduction of dependencies is a permanently recurring problem. Which brings us back to the violation of layering. Every software=20 professional will tell you how very important it is to have a decent=20 layering in your code. Without proper layering, you can't regression- test each layer independently and are thus fallible to all those tiny=20 little buglets that haunt KDE for every new Qt release. Instead of fixing the symptoms, KDE should fix the _cause_. Another point that's missing from the discussion up to now, BTW: Don't you think Kopete and KOffice get *more* testers b/c they run on a=20 stable KDE platform instead of requiring users to upgrade all of the=20 metaphorical dog with the tail? Why else would you want to maintain=20 backwards compat? Marc =2D-=20 It's one thing to accept a risk to your own data, but quite another to standardize on something that imposes that risk on others, no matter how unlikely you think it is that anything "really bad" will happen, and no matter how desirable the outcome. -- Bart Schaefer, on ietf-822 --Boundary-02=_26UJ/oE7avyux/F Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/JU613oWD+L2/6DgRAsyOAJoCCQzvjhkhTdTAOc7VBzhciCyFzACg/Aub Q3HtywXWxNnqJ94t2ogeNtI= =N6PB -----END PGP SIGNATURE----- --Boundary-02=_26UJ/oE7avyux/F--