-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry if the quoting goes amiss somewhere - ironically, my Thunderbird is somehow acting up. I'm trying to fix that manually but I might miss a piece or two.
(Everything I write is, of course, my opinion and, thus, I leave out the "IMO"s and all that stuff.) One thing first: My complaints don't always relate to kdelibs only as you point out correctly. I probably should have responded in a different thread as I was aware of the old kdelibs decision (which I'm not happy about either but that's not my point here). Another introductory point since we don't know each other: I've been a KDE user since the 0.x days. I've been involved in packaging KDE since about 2004 or so. Once you guys had settled into release management, you did a *tremendous* job most of the time. There have always been bugs and there always will be. Same for simple mistakes. No issues with that. My issue is that you need to get back to quality releases (in process mostly, content is a completely different beast) like you did in the KDE 3.x days (especially 3.5.x). On 09.06.2012 12:58, Albert Astals Cid wrote: >> - Missing french documentation for kstars in 4.8.3/4.8.4 > Nothing to do with kdelibs No, but it would loudly have been announced in the KDE3 days by you guys. Next, we (KDE upstream and us packagers) would have figured things out together. >> - a missing Soprano release (to restore SC / BC with a stub impl >> of tcpclient) > Nothing to do with kdelibs (soprano is in fact not even considered > to be part of KDE itself) Yes, but it's an important dependency for KDE and, thus, warrants special focus. In fact, you were willing to call off/delay Beta 1 for it (and rightly so). >> - build failures in one of the "final sets" of tarballs for >> 4.8.4 > It wasn't kdelibs that failed to build No, but speaks volumes of QA if there have to be several "final sets of tarballs". >> - kdelibs and Qt version dependency funkyness > Which funkyness? We need to decide which version to depend on, > don't we? There shouldn't have been any need for such a decision shortly before a release. The Qt dependency should be stable for minor releases (i. e. 4.8.x shouldn't change it). >> And all of that was only *this* week. > Because we are on a release week :-) Sure, but what I actually meant was that there's a lot more earlier - I just didn't feel like digging it all up and documenting it. :-) > KDE releases are not a mess, you seem to think they are a mess > because we discuss everything in public. No, no, I like that. I think they are a mess because of the points I've mentioned re-rolling tarballs, etc. > If we did everything behind closed doors and you only saw the final > output, your impression would be totally different. Again, no, since I saw the process and final output as a packager in the past and today and those two impressions are indeed totally different - just not in the way you mean. ;-) >> I see basically nothing *systematically* being done about it. > Even i don't agree they are a mess, I'll bite and ask if you have > any suggestion. Well, they were mostly in the email I linked you to but here's the gist: - - Before announcing the tarballs, build the whole thing at least 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.) A more radical approach and one I'm personally greatly in favour of: Get rid of time-based release cycles but switch to content-based releases. Instead of rushing things towards the end of a time-based release cycle, describe features/bugs/any kind of content you want to see done before another release. Whatever you guys decide to do (or not do), I'd really appreciate it if you thought about your process and its basics again. Even if you think the releases are not a "mess" there must be a reason some people (some of them being "seasoned KDE veterans" ;-) ) *perceive* them to be one. - -- Best regards, Wulf -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/TOSIACgkQnuVXRcSi+5oGvACfSkqmR1WkQFdshtQP4a3M2xmI RdUAoNJgGjp4OCSQIRm1cM+KFanvtjo6 =czvg -----END PGP SIGNATURE----- _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
