Release Candidate 2 and regressions

[Thomas Zander]

On Monday 02 January 2012 12.19.45 Martin Koller wrote:
> > That's honestly too much for the release team. This has to be taken up
> > within  the teams. The release team doesn't take responsibility for
> > code quality, the maintainers do. If they don't, their software will
> > look bad. Nothing the release team can really do about it.
>
> I understand. So probably what is missing then is a group of decision takers
> who simply can say "yes, we are ready to release" or "no release, there are
> too many glitches, we should not simply release because we scheduled a
> release"

That group of decision makers exists already.
Each component has its own maintainer simply because that person can be the 
only one that can judge the quality best.
So, in this case, the owner of a component can decide to not include it in the 
main release.  kmail did that in the past.
Naturally, for something like khtml, which is part of the kdelibs, this is 
slighly harder.  And one of the things that should go better in kde-
frameworks.

Either way;  I think you are over-estimating the power of the release team. 
The release team can not do all the bugfixing and it can not make volunteers go 
and fix stuff. So its a cooperation with those component maintainers. In true 
open community spirits :)
My point is that its best to take the quality issue in, for example, khtml, up 
with the component maintainers since the actual work rests on their shoulders. 
The release team can not, and should not, force them to fix their bugs.

> I know how open source works as I'm contributing since a lot of years, but
> seriously - until KDE manages to release good quality code it will not take
> enough momentum for really widespread use.

This is a common misunderstanding, and I think Sebas also wrote a really good 
reply elsewhere in this thread.  Bottom line is that while regressions are 
indeed cause for concern, the amount of fixes, new features, and general 
cleanups that KDE manages to put in each release is so much that your 
statement just doesn't get real-world support.  I certainly don't want to 
belittle your list of bugs, but we have to be reasonable and always check our 
premises.

One thing you missed in your conclusion is that in open source the biggest QA 
department is its userbase.  This is why we release often. This is why we have 
a pretty amazing closing rate of user-reported bugs in each release.
And to keep that cycle going, we have to keep releasing often.

Don't worry; the bugfix release after this one is only 1 month away.