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

[Allen Winter]

> On Saturday 09 June 2012 7:53:06 AM Wulf C. Krueger wrote:
>

> 
> - Before announcing the tarballs, build the whole thing at least once.
Absolutely.
We are working on this.  We have a CI system in place (build.kde.org) 
and are just lacking the time and manpower to make it fully functional.

> - Freeze earlier and use the time to do more (systematic!) developer testing.
I think we do pretty well with this on the non-patch releases.
The patch releases are "assumed to work and be incrementally better", for the most part.
We definitely need to have the patch releases built regularly by the CI system.

> - Improve the test cases. They *do* help in catching bugs.
No doubt.
And the failing tests we do have are sometimes ignored.
Again, the CI system should be involved here.

> - Implement more trivial code screening (e. g. for bogus versions).
We can do that.  We do that some.
Once again, the CI system should be able to report problems with bogus versions.
We also need the developers to keep the min version requirements up-to-date
in the buildsystem

> 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.
I feel that the project is too big, with too many moving parts and too many "stakeholders" (is that the word)?
And we don't have full-time management.

But I agree we should revisit this when we start thinking about KDE SC 5