ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+

[Wulf C. Krueger]

-----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-----