From kde-release-team Tue Jun 29 19:52:00 2010 From: "Wulf C. Krueger" Date: Tue, 29 Jun 2010 19:52:00 +0000 To: kde-release-team Subject: Observations and personal conclusions on the KDE release process Message-Id: <201006292152.04944.philantrop () exherbo ! org> X-MARC-Message: https://marc.info/?l=kde-release-team&m=127784918712422 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1644937409==" --===============1644937409== Content-Type: multipart/signed; boundary="nextPart4129318.PL6rdfI22b"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart4129318.PL6rdfI22b Content-Type: multipart/alternative; boundary="Boundary-01=_g7kKMqTdI6m0byP" Content-Transfer-Encoding: 7bit --Boundary-01=_g7kKMqTdI6m0byP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! Please don't take any of the following personally - it's not meant to offen= d=20 anyone.=20 Having been a KDE packager for several years now, I've looked at the releas= es=20 of KDE since 4.0.0. I "felt" that the overall KDE release quality has becom= e=20 noticeably worse than it was during the 3.x days (during which I was most=20 active). I've wanted to compare this feeling to reality, though, and so I consulted = my=20 (incomplete) -packager archive. I wanted to look at release issues, tarball= =20 re-rolls, etc. for KDE4. Since I didn't want dig through everything and avoid a "data overload" for= =20 both me and in this mail, I applied the following restrictions: =2D Ignore alpha, beta, rc and snapshot releases (I looked at them at times= ,=20 though, to verify findings in regular releases and, in general, they suppor= ted=20 my views.) =2D Ignore non-Linux failures, e. g. if things broke for *BSD or Windows, I= =20 didn't count those in. =2D Ignore the KDEPIM situation with respect to KDE SC 4.5. =2D I don't have detailed data from the 3.x days anymore. Whenever I'm refe= rring=20 to those, I'm relying on a) bugtracker data from the distros I've worked on= =20 and b) my memory. :-) =2D I'm missing data about the releases from 4.1.0 to 4.1.3. =2D I didn't re-read every single mail (but mostly those from the tarball=20 announcement threads) so I might have missed some issues. =2D The following conclusions are my own; they are my personal opinions eve= n if=20 not stated explicitly or implicitly in every single case. YMMV. What I observed is this (details at the end): =2D Uploaded tarballs are almost always untested. From a QA perspective thi= s is=20 really bad. Yes, we're packagers and we'll find and report any issues found= in=20 those tarballs to you guys. Nevertheless, build issues - in many cases - co= uld =20 easily be spotted if a simple build test had been done. Most of the time, packager feedback was promptly acted upon and the issues= =20 were resolved with the final tarballs. Sometimes, though, reported issues a= re=20 not followed-up and make it through till the release is out. =2D On average ca. 2,5 tarballs are re-rolled per release. That means that = those=20 who start the packaging process early will have to start over with the=20 respective tarballs. Yes, not all work has to be re-done but again, from a = QA=20 perspective, one should start as cleanly as possible. =46urthermore, having to re-roll that often, more often than in 3.x days, I= MHO,=20 are an indicator for a rushed and/or flawed release engineering process. =2D Another (side-)issue I noticed is the increased number of post-release= =20 bugfixes (compared to KDE3 again) we, as packagers, are asked to apply. Thi= s=20 in itself is very useful and helpful for us, no doubt, but, again, I believ= e=20 this indicates release engineering issues. =2D In several cases, there were more or less trivial (and yet important)=20 reasons for re-rolling tarballs, e. g. wrong version indicators in the=20 sources.=20 A similar issue are the conflicts between oxygen-icons and other KDE=20 components. I wonder if those issues couldn't be tested for automatically t= o=20 avoid such pitfalls. =2D In at least 6 (~30%) of all releases kdebindings were at least partly b= roken=20 (quite a few more if I had counted pre-releases, too). This can have lots o= f=20 reasons and I've not analysed them. It's just an observation. Now, what would I suggest to do about these issues? I'll keep the next part= =20 short - the reasoning can be found above. =2D Before announcing the tarballs, build the whole thing once. =2D Freeze earlier and use the time to do more (systematic!) developer test= ing. =2D Improve the test cases. They *do* help in catching bugs. =2D Implement more trivial code screening (e. g. for bogus versions). =2D Re-think the release engineering process. (No actual, hard suggestions= =20 here.) Again: Don't be offended, please. My only intention is to hopefully help=20 improving the quality KDE (yes, yes, I know KDE is people! ;) ) releases.=20 Last and least, my notes of observations my above comments are based upon. Best regards, Wulf 4.0.0=20 =2D kdebase-runtime and kdebase-workspace missing, then cmake checks broken= , re- rolled =2D kdeedu re-rolled (non-free icon, kstars has wrong version) =2D kdebase-runtime re-rolled (xine-lib check is bogus) 4.0.1 =2D kdebase re-rolled =2D kdebase-workspace re-rolled 4.0.2 =2D kdebase re-rolled (kinfocenter modules moved incompletely) =2D kdebindings re-rolled 4.0.3 Mostly ok. 4.0.4 =2D kdelibs re-rolled (version number was still 4.0.3) 4.0.5 =2D kdebase re-rolled ("crash really often") =2D kdebindings re-rolled (compatibility with SIP 4.7.6) 4.1.4 =2D kdelibs re-rolled (almost no content before) =2D kdebase re-rolled (Copy&Paste files within Dolphin borken) =2D kdebindings re-rolled (left-over svn stuff) 4.2.0 =2D kdelibs re-rolled three times (klockfile fix; kate fix; plasma security) =2D kde-l10n-et broken (parser error : Entity 'turtlelang' not defined) =2D kdebase-runtime (licensing issue) 4.2.1 =2D kdelibs re-rolled =2D kdebase-workspace re-rolled=20 =2D Phonon mess (Qt / stand-alone Phonon) began 4.2.2 =2D kdelibs re-rolled twice =2D kdebase-runtime and oxygen-icons conflict 4.2.3 =2D kdenetwork re-rolled (kopete was broken) =2D kdepim re-rolled (important regressions) =2D kdepimlibs re-rolled (important regressions) 4.2.4 =2D kdelibs re-rolled=20 =2D kdenetwork re-rolled =2D kdepim re-rolled (kaddressbook fails to compile) 4.3.0 =2D kdelibs re-rolled=20 =2D kdebase re-rolled=20 =2D kdebase-runtime re-rolled (nepomuk fix) =2D kdebase-workspace re-rolled three times (wrong version; NM 0.6=20 compatibility; kdm theming) =2D kdeadmin re-rolled=20 =2D kdeedu and oxygen-icons conflict =2D kdeedu re-rolled (compile issues) =2D kdebindings-workspace re-rolled twice =2D kdebindings re-rolled=20 =2D kdepim-runtime re-rolled (compile issues) =2D kdeplasma-addons re-rolled (microblogging applet fixes) 4.3.1 =2D kdebase-workspace re-rolled (wrong version) =2D kde-l10n-pl re-rolled (compile issue: "Entity 'kcontrolcenter' not=20 defined") 4.3.2 =2D oxygen-icons and kdepim conflict. kdepim re-rolled. 4.3.3, 4.3.4, 4.3.5: One tarball re-rolled for each. 4.4.0 =2D Late Virtuoso dependency change. =2D kdelibs re-rolled twice. =2D kdebindings re-rolled (pykde doesn't compile) =2D kdebase re-rolled=20 =2D kdebase-workspace re-rolled=20 =2D kdebase-runtime re-rolled twice. 4.4.1 =2D kdepim re-rolled =2D kdepimlibs re-rolled 4.4.2 =2D kdebindings re-rolled =2D kde-l10n-sv re-rolled (parser error : Entity 'turtlelang' not defined, = cf.=20 4.2.0) 4.4.3 =2D kdelibs re-rolled. =2D kde-l10n-nl re-rolled ('file INSTALL cannot find=20 "/usr/src/packages/BUILD/kde-l10n- nl-4.4.3/docs/kdelibs/preparetips/preparetips.1"') 4.4.4 =2D kde-l10n-sr re-rolled. 4.4.5 =2D All of kde-l10n not timely in-place. --Boundary-01=_g7kKMqTdI6m0byP Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit

Hello!

Please don't take any of the following personally - it's not meant to offend

anyone.

Having been a KDE packager for several years now, I've looked at the releases

of KDE since 4.0.0. I "felt" that the overall KDE release quality has become

noticeably worse than it was during the 3.x days (during which I was most

active).

I've wanted to compare this feeling to reality, though, and so I consulted my

(incomplete) -packager archive. I wanted to look at release issues, tarball

re-rolls, etc. for KDE4.

Since I didn't want dig through everything and avoid a "data overload" for

both me and in this mail, I applied the following restrictions:

- Ignore alpha, beta, rc and snapshot releases (I looked at them at times,

though, to verify findings in regular releases and, in general, they supported

my views.)

- Ignore non-Linux failures, e. g. if things broke for *BSD or Windows, I

didn't count those in.

- Ignore the KDEPIM situation with respect to KDE SC 4.5.

- I don't have detailed data from the 3.x days anymore. Whenever I'm referring

to those, I'm relying on a) bugtracker data from the distros I've worked on

and b) my memory. :-)

- I'm missing data about the releases from 4.1.0 to 4.1.3.

- I didn't re-read every single mail (but mostly those from the tarball

announcement threads) so I might have missed some issues.

- The following conclusions are my own; they are my personal opinions even if

not stated explicitly or implicitly in every single case. YMMV.

What I observed is this (details at the end):

- Uploaded tarballs are almost always untested. From a QA perspective this is

really bad. Yes, we're packagers and we'll find and report any issues found in

those tarballs to you guys. Nevertheless, build issues - in many cases - could

easily be spotted if a simple build test had been done.

Most of the time, packager feedback was promptly acted upon and the issues

were resolved with the final tarballs. Sometimes, though, reported issues are

not followed-up and make it through till the release is out.

- On average ca. 2,5 tarballs are re-rolled per release. That means that those

who start the packaging process early will have to start over with the

respective tarballs. Yes, not all work has to be re-done but again, from a QA

perspective, one should start as cleanly as possible.

Furthermore, having to re-roll that often, more often than in 3.x days, IMHO,

are an indicator for a rushed and/or flawed release engineering process.

- Another (side-)issue I noticed is the increased number of post-release

bugfixes (compared to KDE3 again) we, as packagers, are asked to apply. This in itself is very useful and helpful for us, no doubt, but, again, I believe this indicates release engineering issues.

- In several cases, there were more or less trivial (and yet important)

reasons for re-rolling tarballs, e. g. wrong version indicators in the

sources.

A similar issue are the conflicts between oxygen-icons and other KDE

components. I wonder if those issues couldn't be tested for automatically to

avoid such pitfalls.

- In at least 6 (~30%) of all releases kdebindings were at least partly broken

(quite a few more if I had counted pre-releases, too). This can have lots of reasons and I've not analysed them. It's just an observation.

Now, what would I suggest to do about these issues? I'll keep the next part

short - the reasoning can be found above.

- Before announcing the tarballs, build the whole thing once.

- Freeze earlier and use the time to do more (systematic!) developer testing.

- Improve the test cases. They *do* help in catching bugs.

- Implement more trivial code screening (e. g. for bogus versions).

- Re-think the release engineering process. (No actual, hard suggestions

here.)

Again: Don't be offended, please. My only intention is to hopefully help

improving the quality KDE (yes, yes, I know KDE is people! ;) ) releases.

Last and least, my notes of observations my above comments are based upon.

Best regards, Wulf

4.0.0

- kdebase-runtime and kdebase-workspace missing, then cmake checks broken, re-

rolled

- kdeedu re-rolled (non-free icon, kstars has wrong version)

- kdebase-runtime re-rolled (xine-lib check is bogus)

4.0.1

- kdebase re-rolled

- kdebase-workspace re-rolled

4.0.2

- kdebase re-rolled (kinfocenter modules moved incompletely)

- kdebindings re-rolled

4.0.3

Mostly ok.

4.0.4

- kdelibs re-rolled (version number was still 4.0.3)

4.0.5

- kdebase re-rolled ("crash really often")

- kdebindings re-rolled (compatibility with SIP 4.7.6)

4.1.4

- kdelibs re-rolled (almost no content before)

- kdebase re-rolled (Copy&Paste files within Dolphin borken)

- kdebindings re-rolled (left-over svn stuff)

4.2.0

- kdelibs re-rolled three times (klockfile fix; kate fix; plasma security)

- kde-l10n-et broken (parser error : Entity 'turtlelang' not defined)

- kdebase-runtime (licensing issue)

4.2.1

- kdelibs re-rolled

- kdebase-workspace re-rolled

- Phonon mess (Qt / stand-alone Phonon) began

4.2.2

- kdelibs re-rolled twice

- kdebase-runtime and oxygen-icons conflict

4.2.3

- kdenetwork re-rolled (kopete was broken)

- kdepim re-rolled (important regressions)

- kdepimlibs re-rolled (important regressions)

4.2.4

- kdelibs re-rolled

- kdenetwork re-rolled

- kdepim re-rolled (kaddressbook fails to compile)

4.3.0

- kdelibs re-rolled

- kdebase re-rolled

- kdebase-runtime re-rolled (nepomuk fix)

- kdebase-workspace re-rolled three times (wrong version; NM 0.6

compatibility; kdm theming)

- kdeadmin re-rolled

- kdeedu and oxygen-icons conflict

- kdeedu re-rolled (compile issues)

- kdebindings-workspace re-rolled twice

- kdebindings re-rolled

- kdepim-runtime re-rolled (compile issues)

- kdeplasma-addons re-rolled (microblogging applet fixes)

4.3.1

- kdebase-workspace re-rolled (wrong version)

- kde-l10n-pl re-rolled (compile issue: "Entity 'kcontrolcenter' not defined")

4.3.2

- oxygen-icons and kdepim conflict. kdepim re-rolled.

4.3.3, 4.3.4, 4.3.5: One tarball re-rolled for each.

4.4.0

- Late Virtuoso dependency change.

- kdelibs re-rolled twice.

- kdebindings re-rolled (pykde doesn't compile)

- kdebase re-rolled

- kdebase-workspace re-rolled

- kdebase-runtime re-rolled twice.

4.4.1

- kdepim re-rolled

- kdepimlibs re-rolled

4.4.2

- kdebindings re-rolled

- kde-l10n-sv re-rolled (parser error : Entity 'turtlelang' not defined, cf.

4.2.0)

4.4.3

- kdelibs re-rolled.

- kde-l10n-nl re-rolled ('file INSTALL cannot find "/usr/src/packages/BUILD/kde-l10n-nl-4.4.3/docs/kdelibs/preparetips/preparetips.1"')

4.4.4

- kde-l10n-sr re-rolled.

4.4.5

- All of kde-l10n not timely in-place.

--Boundary-01=_g7kKMqTdI6m0byP-- --nextPart4129318.PL6rdfI22b Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkwqTuQACgkQnuVXRcSi+5q5+wCfb0fFV3uc7dV6SKpwluDMAcf8 QJUAoIlkZiSpLwhZNc8Uz8+NGQsjE0mW =g6B7 -----END PGP SIGNATURE----- --nextPart4129318.PL6rdfI22b-- --===============1644937409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team --===============1644937409==--