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.
