KDE Frameworks 5: Rhythm

[Kevin Ottens]

On Sunday 22 January 2012 12:17:45 Stephen Kelly wrote:
> Kevin Ottens wrote:
> > On Saturday 21 January 2012 20:49:40 Stephen Kelly wrote:
> >> Kevin Ottens wrote:
> >> > On Saturday 21 January 2012 16:17:38 Stephen Kelly wrote:
> >> >> Kevin Ottens wrote:
> >> >> > There's three main reasons for this rhythm:
> >> >> >  * Qt 5.0 feature freeze is upon us now;
> >> >> >  * CMake 2.8.8 will be released in April;
> >> >> >  * it'd be nice to release KDE Frameworks 5.0 at
> >> >> >  Akademy[*].
> >> >> 
> >> >> You mean 'some of the frameworks'? They won't all be done by
> >> >> then.
> >> >> More
> >> >> stuff will need to get into Qt before that's possible.
> >> > 
> >> > Yeah, I know a couple of them will need some merging scheduled for
> >> > Qt
> >> > 5.1
> >> > already (like equivalent to KSaveFile for instance). But if I
> >> > reintroduce
> >> > the few words I forgot to type which were "a technology preview
> >> > of" I
> >> > think it's doable. It means it'd build against "qt master" likely
> >> > earmarked to become 5.1[*].
> >> 
> >> Honestly I don't see a point in aiming so early.
> > 
> > Give no aim, no rhythm and the effort will be on the back burner
> > "forever" (in any case for way too long). Let's be honest with
> > ourselves here: that's the biggest risk we face right now.
> 
> Maybe it is the biggest risk.
> 
> There are big problems that affect scheduling attempts too, such as there
> being a lot still to do in our upstreams, and not enough people who have
> enough expertise to contribute to the effort doing so. Maybe a schedule will
> attract them. I don't know.

Well for the upstreams (Qt and CMake), of course I don't expect an army to 
rise up because of a schedule. That said my understanding from discussion with 
Alex is that CMake is pretty much under control.

That leaves us with Qt, indeed that's problematic, I don't have a solution for 
it at that point but I doubt it's reason enough to force us to stagnate. We 
have to workaround blocking points in the meantime to keep having splitting 
occur in kdelibs.

I mean... back in the days of Platform 11 all the thinking was: "let's have a 
perfect scenario and a scenario where the open governance doesn't happen" (at 
the time open governance wasn't in place yet). It's pretty much still the same 
way of thinking we have to keep there, except the focus moved from "no open 
governance" to "not enough people doing the Qt merges".

Of course, I still wish we'd have more people with the expertise and energy 
for those merges in Qt. But wishes don't turn into code, it'd be irresponsible 
to wait for that code to happen to push further the splitting.

> > Honestly for a technology preview we don't necessarily need a large PR
> > around it, and you should expect it to burn your house and to change a
> > lot if necessary.
> 
> Fair enough. If the point is to get people to try it though it will need
> some sort of PR and 'release'.

That's why I said "large PR". But yes we'll need a release and an announcement 
for it.

> > Who talked about a freeze? Not me at least. And I honestly
> > don't think we should take decisions based on some hypothetical people
> > ranting and some future threads in mailing list which didn't appear yet.
> > Fear based decision taking is the best way to derail a project or have
> > an
> > inadequate outcome.
> 
> Ok :). Lets just agree to ignore such threads if they do appear and not
> respond. That doesn't affect anything about what tech news outlets will
> write though :).

I couldn't care less about what news outlets will write in the future. Of 
course it's up to us to announce from day one: "it'll burn your house". Our 
job is to be honest regarding the state of KDE Frameworks when we release 
something and announce it. The tech news journalist job is their... they can 
act professionnally or not, we won't have control on it anyway.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120122/117e74b3/attachment.sig>