Re: Observations and personal conclusions on the KDE release process since 4.0
Hi, On Thursday 01 July 2010 02:37:30 Maciej Mrozowski wrote: > On Wednesday 30 of June 2010 20:23:18 Simon Edwards wrote: > > The main issues for this cycle, IMHO, have been: > > > > * branches - Things being branched off earlier than expected, or work > > branches being merged later in the process make it harder to keep track > > of what exactly is going to be in 4.5. > > My thoughts exactly. But it's not only that. > Why do you guys branch off before minor release? (4.x.0). Time between rc1 > and release is important as important fixes usually are commited in this > period. And while trunk and recently branched off code doesn't really > differ much, That's an incorrect assumption actually. As soon as you re-open trunk, people start committing larger patches (makes complete sense, it's the beginning of a development cycle, meaning plenty of time to test and stabilize these features). Also, as Aaron points out often UI changes that have been held back go in. > any fixes *have* *to* be applied to both branches, otherwise > trunk will be affected again. And while back/forward porting fixes is > troublesome I suppose some fixed simply don't make it to both branches > (forgotten, people being unaware of the need to fix both branches etc). > > Branching off relatively late (maybe even after minor release, not tagging, > just in any case) would also (hopefully) mean a little shift towards > "maintenance" from "new features" seemingly forcing developers to focus on > polishing not-yet-released version instead of "working in trunk". > (which I believe may upset many developers and they'll choose to work in > playground/local branches nevertheless). Freezes come at a cost, because they force developers to hold back on their work, to share it later. We need to find a good balance between "frozen, only critical fixes (which ist what the RC period is for), and ongoing development. As to the bindings problems you've talked about, I think this cycle's API freezes (which we introduced exactly to tackle that problem) seemed to work quite well. Of course we can only tell once 4.5.0 has working bindings out of the box without Dirk going out of the way or calling Simon in to fix last- minute problems). We've introduced a freeze for dependencies as well, so let's see how this goes. Wulf, thanks for your analysis by the way. I think it's critical to look at our own processes this way. I do think, however, that we're quite aware of at least some of the problems, and we're well underway improving on it. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Observations and personal conclusions on the KDE release process since 4.0
On June 30, 2010, Maciej Mrozowski wrote: > Branching off relatively late (maybe even after minor release, not tagging, > just in any case) would also (hopefully) mean a little shift towards > "maintenance" from "new features" seemingly forcing developers to focus on speaking as an app developer: we just spent the last 7 weeks doing this. there's no need to force anything here. thanks to the branching, i was able to commit 2 bug fixes that required string changes. others can start merging their feature branches which were happening anyways (no amount of time in extra freeze would change that). and we're still seeing numerous commits to the 4.5 branch. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Observations and personal conclusions on the KDE release process since 4.0
On Wednesday 30 of June 2010 20:23:18 Simon Edwards wrote: > The main issues for this cycle, IMHO, have been: > * branches - Things being branched off earlier than expected, or work > branches being merged later in the process make it harder to keep track > of what exactly is going to be in 4.5. My thoughts exactly. But it's not only that. Why do you guys branch off before minor release? (4.x.0). Time between rc1 and release is important as important fixes usually are commited in this period. And while trunk and recently branched off code doesn't really differ much, any fixes *have* *to* be applied to both branches, otherwise trunk will be affected again. And while back/forward porting fixes is troublesome I suppose some fixed simply don't make it to both branches (forgotten, people being unaware of the need to fix both branches etc). Branching off relatively late (maybe even after minor release, not tagging, just in any case) would also (hopefully) mean a little shift towards "maintenance" from "new features" seemingly forcing developers to focus on polishing not-yet-released version instead of "working in trunk". (which I believe may upset many developers and they'll choose to work in playground/local branches nevertheless). -- regards MM ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Observations and personal conclusions on the KDE release process since 4.0
Hello, On 06/29/2010 09:52 PM, Wulf C. Krueger wrote: > 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). Thanks for the input, and the summary. After the 4.4 release cycle which don't go so great, we tightened up the freeze schedule somewhat with regard to no-commits before tagging, clearer dependency freezes and better communication when changes to header files are done (i.e. mail kde-bindings@). So far my impression is that the release cycle which we are in right now has been running much smoother than in the past. I'm saying that with my bindings hat on. From my point of view there have been less last minute surprises. The main issues for this cycle, IMHO, have been: * unclear dependency requirements - i.e. exactly which versions of things are required by KDE. This info doesn't seem to be collected in one place. The problem is actually getting worse since KDE has more dependencies than in the past, and because components/subprojects have been migrating out of svn to git elsewhere. * branches - Things being branched off earlier than expected, or work branches being merged later in the process make it harder to keep track of what exactly is going to be in 4.5. I guess there is still work to do. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall si...@simonzone.com | http://www.simonzone.com/software/ Nijmegen, The Netherlands | "ZooTV? You made the right choice." ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Observations and personal conclusions on the KDE release process since 4.0
Am Dienstag 29 Juni 2010 schrieb Wulf C. Krueger: > 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). > Hi Wulf, Thanks for your effort to give a feedback on the status quo. I'm sure there are points in your analysis to improve the process. But I can't get one thing left uncommented: we _did_ rerelease KDE 3 tar balls a lot to the packagers and most of the times, KDE3 _tar balls_ were untested too (developers update their svn, recompile and if it worked, they assume it works good enough to create tar balls). And KDE4 is not only much bigger, also e.g. the interest in working bindings is much higher. In KDE3 times, it was very often only noticed far after release and still not many cared. To not release ready tar balls to the packagers, means hours and hours that are wasted with only one guy testing when many more could test at the same time. And hopefully it's clear to every packager, that prerelease tar balls are prerelease. If not, your mail is a good start to clarify that :) Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Observations and personal conclusions on the KDE release process since 4.0
On Tue, 29 Jun 2010 21:52:00 +0200, "Wulf C. Krueger" wrote: > Hello! > > Please don't take any of the following personally - it's not meant to > offend > > anyone. Hi, Thanks for the overview, it was a nice read. While you have valid points, some are not. The biggest problem you seem to have is with announcing untested tarballs. You have to understand that we are announcing them to the packagers. They help to find problems with the tarballs. That's perfectly fine. If they have a problem and don't want to run into the chance of starting from scratch, they can wait untill we officially announce the tarballs. At that point the tarballs are ready and with help of the distro's that do have tried to build it, we know for a fact that it will build on almost every machine. The option to prevent this is, as you suggested, to first build everything our self. Then pass it to the packagers so they can prepare packages, then announce it. That will set us back a week in every release. This is not possible as in that case there would for example be a week between release and the next tagging, which gives no time to incorporate bugs from a previous release. QA-wise even worse. Last point I would like to comment about is your statement that an increase in minor releases says something about the quality. That's untrue, the minor releases are time based (released at the first Wednesday of the month iirc) and or not based on the amount of bugs solved at all. Again thanks for the overview, I'm sure I'll scan through it again when making the next round of schedules and see if we can improve some items. -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Observations and personal conclusions on the KDE release process since 4.0
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 /
