KDE Frameworks 5: Rhythm
Stephen Kelly
steveire at gmail.com
Sun Jan 22 11:17:45 GMT 2012
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.
>
> Having monthly check points, and a bigger one in a while where we try to
> see how a end-user release would look with the current state (give it the
> name you want I'd call that Technology Preview 1) are IMO the best way to
> get people motivated (sense of achievement) and to reassess your plans
> efficiently (early feedback).
>
>> It makes mistakes and 'I
>> thought it would behave like ABC' more risky and costly. I know you're
>> 'only' talking about technology preview, but once a technology preview is
>> out, some people will say things like 'We shouldn't change things
>> significantly now that the technology preview is out' and there will be
>> long threads on some mailing list somewhere.
>
> 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'.
> 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 :).
>
>> > Come on, it's just *almost* impossible? So still deserves to be
>> > attempted.>
>> > :-)
>>
>> By someone, but not me. (Apart from the timezone stuff which I am willing
>> to do, but it's likely that if I try to submit it to Qt it will be
>> blocked with 'What does John Layt say', which I can't answer because I
>> can't get a hold of him).
>
> On that topic John apparently reappeared recently so I'd expect some
> improvement. If not we should act soon indeed.
Yes, I have been attempting to discuss it for a while.
I'll just try to move on without his input I guess. David Jarvie did see the
sense in the proposal, so that's a good start (though I think John might
officially be the maintainer of the stuff in Qt).
Thanks,
Steve.
More information about the kde-core-devel
mailing list