This starts to become a dangerous path (Was: New Feature for kdelibs)

Wed Nov 16 16:31:29 GMT 2011

On Tuesday, November 15, 2011 16:28:21 Scott Kitterman wrote:
> On 11/15/2011 04:08 PM, Thomas Lï¿½bking wrote:
> > If one wants a feature in future KDE versions and such fork wouldn't
> > exist, one would not add it at all rather than to the frameworks?
> > Doesn't make any sense to me, sorry.
> 
> That's true, but the question is when.  For developers focused on more
> near term things than Frameworks, it's unlikely they'll help with
> Frameworks in order to get their feature out faster.  Are there any
> examples of people who started working on the Frameworks port because
> kdelibs 4.8 doesn't exist?

yes, though granted few, which is to be largely expected because frameworks is 
new and in addtion despite coming to this list with a _consensus decision_ by 
the _current maintainers and bulk of developers_ we have not received the kind 
of cooperation and support that one might be led to expect from the KDE 
community.

in any case, because i've been strict about this with libplasma2, people have 
contributed to the frameworks branch (though sporadically as frameworks is 
still fledgling).

beyond new people, it is just as important that this allows those of us who 
are working on it to do so without spending time forward porting. every time 
the KDE/4.7 branch changes, it slows us down as we then have to merge-and-fix 
(both into frameworks as well as master, btw). realize, as noted already, that 
as frameworks progresses these merges will become harder and more labor 
intensive.

with the "let things flow into KDE/4.7" approach, controlled or not, we not 
only lower incentive to work on frameworks but we make the efforts that are 
going into frameworks less efficient. the math is very evident from that point 
forward for what that means for frameworks.

again, we've walked this path before. we know how this turns out. we can 
improve how we do things.

> 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.  I think 'fork' is a very strong word and it's
> really overkill for the case we're discussion.

agreed. i stil think there are significant risks for downstreams in this.

> > kdelibs or frameworks are not features but locations, but people are
> > interested in feature, not in locations.
> 
> They are also interested in timeframes.

agreed. and the answer is for us to get those timeframes together.

this is something i've committed to getting done since that ball got dropped. 
the answer, however, is not to therefore make those working on frameworks 
harder, which is like working around a bug when we can just as easily fix the 
bug.

> > Eg. Valentin wants his SecretService to be used by KDE software - if
> > that means to add it to frameworks, he'll add it there. If it means to
> > add it to kdelibs, he'll add it there.
> > Everything else would be religious nonsense.
> 
> It also means that if there are applications making use of it before KDE
> Frameworks is out, then it'll be left to distros to figure out how to
> stitch it together with the existing kdelibs to make it work (or just
> give up on the newer applications/features).  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.

we are already doing this with kactivities, however. and will be doing so with 
ksecretservice. so your concern is simply unfounded.

i think i may see a very important stumbling block here: many of us are still 
thinking of kdelibs as a monolithic thing. frameworks is going in the other 
direction and increasing modularity (we will be keeping the monolithic option 
for those who don't want to be bothered with a dozen new repos :)

the only issue is with new features to existing libraries (and we've worked 
around this for KWallet...) and then it's like _any other kdelibs release_: it 
will be in the next feature release. we want this cycle to be medium length: 
it will be more than the usual 6 months, but if we coordinate together we can 
make FAR FAR shorter than the *3 YEARS* that the last revamp took (also for 
KDE 2) or the ~2 years (iirc?) that 3.0 took. we want sometihng more like 3.0, 
which took under a year. but that will only work if, like 3.0, we keep the 
scope manageable and people work together.

> >> I fail to understand it either
> > 
> > You really meant: "Why not add it to the application (link static) and
> > put it into frameworks later"? (as i wrote.)
> 
> No.  I meant I don't understand how telling people their work can't go
> into KDE SC 4.8 will incentivize them to work on Frameworks.  If they

their work is welcome in frameworks. they merge it there (two people have now 
done this that i know of, off hand) and ipso facto they are now working on 
frameworks. great :)

> are interested in Frameworks, they're probably doing it already.

no, they aren't. i know this because the number of people who have asked me 
how to do so outnumber the people working on it. we have not done a good 
enough job of documenting goals, timelines and open tasks. i will be helping 
to address this issue later this month at the irc meeting that was already 
posted.

> My suspicion is that KDE Frameworks will stay on the path
> it's on and the rest of us need to figure out how to deal with it.

the best way to "deal with it" is not to consider it a fork of kdelibs but the 
next version of kdelibs (that's what it is) and help out with it :)

another way of putting is: please don't fighting your own teammates (the ones, 
in this case, who have done the majority of kdelibs work in the last few 
years), but join then.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111116/e6ddd2d4/attachment.htm>
-------------- 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-core-devel/attachments/20111116/e6ddd2d4/attachment.sig>