From kde-core-devel Wed Sep 27 11:55:38 2000 From: Matthias Elter Date: Wed, 27 Sep 2000 11:55:38 +0000 To: kde-core-devel Subject: Re: KDE2 release schedule update X-MARC-Message: https://marc.info/?l=kde-core-devel&m=97005572015541 On Tue, 26 Sep 2000, Dirk Mueller wrote: First of all, please also read my answer to Waldo. > - everybody reading kde-bugs-dist or kfm-devel will know that we're flo= oded > with konqueror/khtml/kjs/kjava related bug reports. The are a huge amou= nt > of issues left, i.e the referer problem or form post/cookie problems th= at > make konqueror/khtml unusable for real world usage - so many of > them that I'm unsure if it is a clever idea to release KDE2 > currently at all - remember the GNOME 1.0 effect. But as this seems to = be > decided lets not discuss it again. > The important point is: we will need to do a lot of changes to > khtml/kjs/kjava. None of them only qualify as "bugfixes", because most > problematic webpages we get reports on rely on certain unimplemented > features in the lib. this means that all commits would go to the > KDE_2_0_BRANCH, leaving the bugfixing branch behind. KDE 2.0.1 is intended to fix the most critical bugs the large user base w= e=20 will have as soon as it is adopted by the distributors will find. Problem= atic=20 web pages are not critical. I can work with KDE even if kthtml can't rend= er=20 ww.foobar.com. I can't work with KDE if say kwin crashes every 2 hours on= =20 certain systems.=20 > - We lack of resources maintaining two different branches. as you can s= ee > several non-core developers even now don't run KDE2 but only develop fo= r it > under KDE1. This situation will be worse if we split KDE2 in two differ= ent > branches. There will be almost no people who regularly checkout both > branches and see if they still work. So the quality insurance of one of > those branches (and my guess is it will be the bugfixing branch) is equ= al > to zero. That's insane. KDE was getting good in the past because every > developer runs it all the time, so he actually triggered all the most > common issues somewhere in the code by himself. This won't happen any m= ore > with the above schedule, because I know that every developer likes to w= ork > on new features instead of doing bugfixing and optimizing. So there wil= l be > a huge number of new feature commits in the feature-branch, which will > diverge both branches even more, making it less possible to apply the s= ame > bugfix in both branches with acceptable amout of work. The KDE_2_0 branch wont live longer than a few weeks. As I explained abov= e=20 it's only purpose is to release a version of KDE 2.0 that fixes "show=20 stoppers" we find after the "show" (and we _will_ find some) fast. It is = also=20 important to have that branch to be able to fix security problems people = find=20 in KDE 2.0 fast. Those of us who are paid to work on KDE by a company who= is=20 interested to have a 2.0.1 release soon after 2.0 (and I bet all distribu= tors=20 are) _will_ have to commit fixes to the KDE_2_0 branch. > - try to learn from the linux kernel development. they don't do much ri= ght, > because they don't use any source versioning system like CVS etc., but = even > they know that its a bad idea to launch a bugfix and a new feature bran= ch > at the same time. We should get stable what we have and make it better = in > small steps. if there is a new feature or two in the bugfixes it makes = the > people happy and actually makes them willing to upgrade. As I said, the branch wont see any bugfix commits other than fixes for=20 critical bugs or security holes. You can't compare this to the stable 2.2= =2EX=20 kernel branch that sees feature commits. > > - think about the distributors. they constantly have the problem of too > less space on too few CDs. do you think they will ship the KDE bugfixin= g > branch as well as the KDE feature branch on their CDs, besides GNOME an= d > half a dozen other windowmanagers? They will decide for one of them, ei= ther > the bugfixing branch or the feature branch. If they decide for the > bugfixing branch, it's a bad decision for us because nobody will notice > that KDE2 actually evolves, that means it adopts new features and got n= ew > eyecandy applications. That's like a shot in our own foot. > on the other side, if they decide on the feature branch, they will neve= r > ship a seriously stable environment because that branch isn't supposed = to > be stable. This will not only be a shot in our foot, but also in our he= ad > because it kills of biggest advantage over competing desktop > environments: being stable _and_ useful. Hm? Distributors will ship KDE 2.0.1, the fixed version of KDE 2.0 until = we=20 release KDE 2.1. What is your point? We wont have bugfix/feature branches= =20 like the Linux kernel has!!! > - think about the i18n teams. Do you really think they will translate b= oth > the bugfixing branch and the feature branch? They asked us about a stri= ng > freeze _months_ before KDE2 release because they want to catch up with = the > new strings introduced! they won't be happy about that desicion that > effectively doubles their work! Same as above, this is not about linux kernel style bugfix/feature branch= es!=20 There wont be message changes in KDE 2.0.1. (...) > Thanks for reading, It was a pleasure. Although I could have enjoyed it even more if it was a= =20 little bit shorter and to the point. ;-) Greetings, Matthias --=20 _____ ___ / __/____/ / Caldera (Deutschland) GmbH / /_/ __ / /__ Naegelsbachstr. 49c, 91052 Erlangen /_____//_/ /____/ Matthias Elter, email: me@caldera.de =3D=3D=3D=3D /_____/ =3D=3D=3D=3D=3D=3D phone: ++49 9131 7192 300, fax:= ++49 9131 7192 399 Caldera OpenLinux http://www.caldera.de