Fwd: KDE Frameworks Release Cycle
Frank Reininghaus
frank78ac at googlemail.com
Tue May 20 14:41:04 UTC 2014
Hi,
2014-05-20 13:19 GMT+02:00 Scott Kitterman:
> We've pushed nearly every point release to end users throughout the KDE4 cycle. I use them myself. Your characterization of the KDE4 point releases doesn't match my experience.
here is just one recent example, where someone pushed a commit to the
KDE/4.13 which seemed to work fine for him:
https://git.reviewboard.kde.org/r/117044/
The next ones to test the patch were the users who upgraded from KDE
SC 4.13.0 to 4.13.1, and then noticed this regression:
https://bugs.kde.org/show_bug.cgi?id=334776
I know that such things do not happen in every bug fix update, of
course. Most of the time, they do improve the user experience
considerably, but there is always the risk that things turn out pretty
badly for some users. Nevertheless, I still appreciate the possibility
to release regular bug fix updates, and I am very grateful that the
packagers invest a large amount of time each month to help with that!
Please let us all acknowledge and appreciate that everyone here tries
to provide a great KDE experience to users, and possibly make it even
better in the future.
* Packagers appreciate the possibility to ship monthly bug fix updates
to users, and I guess that most of us understand and appreciate that.
On the other hand, they cannot ship updates that contain anything but
bug fixes - I think that we just have to acknowledge that this is due
to distro policies that will not be changed for KDE Frameworks.
* Frameworks developers would like to provide regular updates to users
which are tested well (in order to prevent annoying regressions which
ruin the user experience, and possibly, also KDE's reputation).
It has become obvious that the initial 1-month release cycle plan
might not work out fully as expected due to distro policies which will
not change. But in any case, even if a distro would not update the KF5
version that it shipped with initially at all, then at least we would
prevent that code which has seen little to no testing appears on
user's machines, and this is a good thing. And if we can find ways to
improve that, then it's even better.
Thanks and best regards,
Frank
More information about the release-team
mailing list