Koehne Kai [kai.koe...@digia.com] > > [...] > > > Before merging a feature the maintainers consider if yes or not the > > > feature is ready for integration. If bad decisions are made, I don't > > > think the "time- based" releases have anything to do with that. > > > > It has to some degree, because it leads to rushing features in before the > > deadline; and then API reviews, blatant bug fixes, writing examples, source > > cleanups, etc. happen in stable after the merge (and not, as I said, before > > even merging into dev). > > The thing is, you can't get out any release of something as big as Qt > without deadlines. And with deadlines comes the rush to get stuff in ...
Worse, it creates a bias. When the more responsible people hold back their changes early to not delay the release and others keep shuffling in rushed last minute implementations, the majority of features will be rushed. > [...] Maybe we do indeed take features in too lightly. And maybe we > have to be more strict following up on new features to make sure > that they're really polished & ready at release time. But for all of > this, having a predictable schedule is IMO a necessary prerequisite. Not "maybe", it's certain. It's dead easy to get a feature in, especially in modules that are not as tightly controlled as qtbase. And it's basically impossible to get something out again, due to the "binary compatibility promises". So we keep accumulating semi-broken, politically "unfixable" stuff, making Qt fatter, and stretching out resources thinner and thinner. And this _is_ a pure policy issue, nothing technical here. To stop this trend, there must be a tight reign on feature development in _all_ modules. Having a centralized "joint API sanity master instance" would definitely be a step into the right direction. It sort of used to work at a time... Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development