<p><br>
Am <a href="tel:30.12.2012%2001">30.12.2012 01</a>:18 schrieb "Sebastian Kügler":<br>
> r<br>
> On Friday, December 28, 2012 21:54:17 Andreas K. Huettel wrote:<br>
> > Seriously. I know I'm probably just putting my foot in my mouth once more<br>
> > here, but:<br>
> ><br>
> > What are betas and rc's for, if not for stabilizing code and progressing to<br>
> > smaller and smaller non-intrusive changes? If you decide do kick out and<br>
> > replace a large chunk of code between rc1 and rc2, 2 weeks before release,<br>
> > you may as well re-label the 4.10.0 release "beta1".<br>
><br>
> Maybe we should do that. Vishesh has a patch for Dolphin's filepreviewer that<br>
> is also waiting, and with the akonadi Nepomukfeeder fixes, we could consider<br>
> putting another release candidate in, do the actual release three weeks later<br>
> than planned, BUT ship an SC with much improved Nepomuk, which will probably a<br>
> lot of users happy. Aside from that, the testing initiative was geared up a<br>
> bit late this time around, we only announced that in the last RC.<br>
><br>
> Who would be in favour of inserting another RC and three weeks to get<br>
> Christian's and Vishesh's Nepomuk patches in *and* rockstable? Would it create<br>
> any timing problems for distros that are going to ship 4.10? How does testing<br>
> and user feedback look so far, with RC1?</p>
<p>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:</p>
<p>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.</p>

<p>But I am worried that this might do more harm than good in the long term:</p>
<p>a) It might frustrate those developers who worked hard to get their features ready before the freeze.</p>
<p>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.</p>
<p>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?".</p>

<p>I realise that some people might not like what I'm saying here, but I just have to<br>
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.</p>
<p>But I see that the decision has been taken already, so never mind.</p>
<p>Best regards,<br>
Frank</p>