This starts to become a dangerous path (Was: New Feature for kdelibs)
thomas.luebking at gmail.com
Tue Nov 15 22:05:42 GMT 2011
Am Tue, 15 Nov 2011 16:28:21 -0500
schrieb Scott Kitterman <kde at kitterman.com>:
> Are there any examples of people who started working on the Frameworks port
> because kdelibs 4.8 doesn't exist?
I don't know and that's still not the topic.
I didn't and do not suggest that developers who want features in KDE
would start to dig in whatever is on the tops of the frameworks lists
to get it in faster.
Just that if they get it into some fork it might prevent them from
adding it to frameworks at all.
> > It might not in all occasions be possible to add it to kdelibs and
> > frameworks at the very same time.
> That's true. I think that improves the case for doing the work to
> support 4.8.
Whether or not, it doesn't invalidate the troubles with a moving target.
> I agree with that, but we are talking about a limited number of
> features required for specific applications, not a free for all of
> feature changes for change sake.
Yes, for now. The question is whether it's possible to make exceptions
here and deny them later.
There will always be "that one thing" and at some point you will need a
It certainly doesn't HAVE to be now, but it's reasonable to assume that
an earlier deadline will lead to an earlier result.
> I think 'fork' is a very strong word and it's really overkill for the case we're discussion.
Valentine & Kevin? No. But if it was for 4.8 only we'd not be leading
this discussion anyway I assume?
> It also means that if there are applications making use of it before
> KDE Frameworks is out
And that is gonna happen in what way if it's not in any lib?
Static linking?! External lib? Problem solved?
> then it'll be left to distros to figure out
> how to stitch it together with the existing kdelibs to make it work
That sounds like the libactivity case, I can and am not gonna comment
that for the moment.
> Unless no one will make use of the work for things that are released before
> Frameworks is released, keeping it out of kdelibs just makes things
> harder for distributors.
That is basically why i later one, well, suggested to make frameworks a
dependency of kdelibs.
> Fortunately no one is talking about doing that.
Coordination? I thought so. The fork will or will not happen implicitly.
Said "dangerous" not "disastrous" ;-)
> > You really meant
I thought so :-p
More information about the kde-core-devel