Change release schedule 4.2 and schedule for 4.3
Mauricio Piacentini
piacentini at kde.org
Wed Sep 10 01:35:53 BST 2008
Cornelius Schumacher wrote:
> This is one of the core problems we have to address. It's not a healthy
> separation, if people don't care about fixing the bugs of their own code, but
> let others do it.
Agreed, but how to force them to fix the bugs? My reasoning is that
ideally we would need to get better at avoiding the bugs getting in
trunk, and this is where a different (descentralized) source code
management tool could help, by allowing easier review of patches and
development of features in parallel. But this is not the only action
that could help us "lock the bugs out": I think that one point mentioned
by Thiago (the importance of testing) is what we really need, at least
in KDE Games. We talked about this during last Akademy, at our BoF.
Currently we rely on the game author to test new features, basically,
and on the goodwill of very few peers. I do not have an answer for how
we could improve this, but I feel that a system that allows easier peer
review and cherry pick of features BEFORE they get in trunk could help
us improve the quality. These better tools for collaborative reviewing
of patches and merging could also help us run bug-killing marathons,
perhaps. But none of this really depends on the release schedule, does
it? In an ideal world, we should be killing bugs as they are spotted,
and not only when the release is near.
Regards,
Mauricio Piacentini
PS: of couse in this ideal world we would also be all paid to work on Qt
24x7, and we would have 10x the number of developers we have now, all
very much interested in following bugzilla :)
More information about the kde-core-devel
mailing list