KDE Quality (problems)

[Duncan]

Kevin Krammer posted on Sun, 17 Apr 2011 17:19:23 +0200 as excerpted:

>> Ad 2.)
>> Another problem is the release cycle. The cycle is so short, that even
>> many bugs reported during alpha stage aren't fixed. At release-time,
>> devs are already working on new features, often not backporting their
>> fixes.
>> So you end up again with release+1, this time with other bugs.
>> 
>> Its not uncommon for me to see integral parts broken after updating to
>> a new major (like the panel in my multimonitor setting when updating to
>> 4.6).
> 
> I don't think it is actually the length of the release cycle itself, my
> guess is that it is more of a question of the ratio between unfrozen and
> frozen periods within the cycle.
> 
> This is one of the things that hopefully will get better due to the
> recent switch to git as our version control system.
> While SVN did support branching, tracking changes across several
> branches became quite difficult, resulting in most development to happen
> in trunk.
> 
> git is a lot better in this regard, allowing development parallel to
> several releases, i.e. basically making it possible to only fold back
> fully implemented new features.
> So each release cycle's unfrozen period could be shortend considerably,
> e.g. like the Linux kernel's merge windows.

You're absolutely right, there.  Even tho this switch svn -> git has been 
painful for 4.6, I'm solidly behind it, as I know from experience what it 
has done for the kernel.  I don't claim to be a developer, but do like to 
run pre-release level code[1], and despite not doing code, I now regularly 
file and bisect bugs down to individual commits.  There's no way I'd be 
doing that were it not for git.

Which is why I'm so happy to see kde picking up git.  There's a huge 
upside in potentially /effective/ bug-filing there, bisecting to the 
individual commit, etc, as I routinely do on the kernel now, that could 
drive kde forward at a pace it can only dream of, ATM, and what's more, 
being the more stable for it (instead of as above, moving too fast to 
stabilize), as well!

Now kde's a MUCH bigger project in terms of compile-time than the kernel, 
and I'm not sure even the kde folks really know for sure how that's going 
to work out, but especially if it's possible to go-live-git for only one 
module, while keeping the others to release or at least the most recent 
semi-stable preview release, it could work, and ccache, etc, are pretty 
dramatic build-speed boosters for those who build at least a couple times 
a week.  Whether they make it reasonable to git-bisect or not I don't 
know, but it'll certainly be interesting to see how things develop, for 
sure!

[1] When, ummm... said pre-release code is represented as what it is, not 
alpha called release.  Can't really file bugs on alpha because the devs 
already know the functionality's not implemented yet.  The devs were 
saying just that (functionality not yet implemented) with 4.2 and even 
4.3, even as they were still claiming it was ready for ordinary use! But 
4.5 finally hit reasonable release quality, IMO as an experienced early 
release tester, so that's done, but the broken trust isn't fixed by simply 
creating the software to fill the gaps.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.