Another RC?, was: Re: Akonadi-Nepomuk Feeder Improvements

[Frank Reininghaus]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20121231/f976d4f9/attachment.html>