Am 30.12.2012 01:18 schrieb "Sebastian Kügler": > r > On Friday, December 28, 2012 21:54:17 Andreas K. Huettel wrote: > > Seriously. I know I'm probably just putting my foot in my mouth once more > > here, but: > > > > What are betas and rc's for, if not for stabilizing code and progressing to > > smaller and smaller non-intrusive changes? If you decide do kick out and > > replace a large chunk of code between rc1 and rc2, 2 weeks before release, > > you may as well re-label the 4.10.0 release "beta1". > > Maybe we should do that. Vishesh has a patch for Dolphin's filepreviewer that > is also waiting, and with the akonadi Nepomukfeeder fixes, we could consider > putting another release candidate in, do the actual release three weeks later > than planned, BUT ship an SC with much improved Nepomuk, which will probably a > lot of users happy. Aside from that, the testing initiative was geared up a > bit late this time around, we only announced that in the last RC. > > Who would be in favour of inserting another RC and three weeks to get > Christian's and Vishesh's Nepomuk patches in *and* rockstable? Would it create > any timing problems for distros that are going to ship 4.10? How does testing > and user feedback look so far, with RC1?
I realise that I'm a bit late. I'm on holiday and have only limited internet access. But anyway, here are my 2 cents: I appreciate that Vishesh and Christian are trying to improve the user experience in KDE 4.10, and I appreciate that people offer help with testing and try to find ways to get these commits into 4.10.0, even if they are a bit late. I see that the "add another RC and allow those features in" idea might bring a short-term benefit for KDE's user experience. But I am worried that this might do more harm than good in the long term: a) It might frustrate those developers who worked hard to get their features ready before the freeze. b) It might frustrate those who did not get their features ready before the freeze in early November and put up with the idea that they have to wait until KDE 4.11. c) It encourages more people to follow the same approach in the future. What are we going to say in 6 months if a dozen people say: "Why can't we just delay the KDE 4.11 release and include my feature? We did that before, why not now?". I realise that some people might not like what I'm saying here, but I just have to say it because I believe that the benefits of a predictable release schedule are worth more to the community in the long term than a couple of improvements in 4.10.0. But I see that the decision has been taken already, so never mind. Best regards, Frank
_______________________________________________ Kde-testing mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-testing
