[Development] On the effectiveness of time based releases

[Poenitz Andre]

Koehne Kai [Kai.Koehne at 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'