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

[Scott Kitterman]

On 11/15/2011 02:46 PM, Thomas Lübking wrote:
> Am Tue, 15 Nov 2011 13:17:45 -0500
> schrieb Scott Kitterman<kde at kitterman.com>:
>> It is probably worth a discussion on packagers to share cross-distro
>> ideas about what kdelibs feature patches to ship with 4.8.
>
> While Scott's suggestion to have a commonly downstream patched
> kdelibs 4.8 may on first sight seem to make a lot of sense, this is
> essentially the path to a major fork of kdelibs.
>
> I guess nobody does or would like such situation, since it will
> a) drain sources from KDE frameworks

Only if the people that would work on this would otherwise work on KDE 
Frameworks.  AFAIK, that's not the case.

> b) eventually lead to a lead lock, since if applications (a library
>      itself is worth nothing) start to rely on that features (4.8, 4.9,
>      4.10?!) which have been added to the fork but not been integrated
>      (this way) into frameworks, the applications are spellbound to the
>      fork to avoid a regression - or porting things from kdelibs into
>      vivid (ABI/API stable) frameworks, what to avoid all this trouble
>      is about in the first place.

I'm not aware of any cases where people wanted a new feature where they 
didn't also say they would forward port it to KDE Frameworks. 
Personally I wouldn't be in favor of accepting a distro patch for 
something that wasn't going to end up upstream.  For this purpose, 
that's got to be frameworks.

> c) ultimately waste energy to either or both and the work to resolve
>      the result

I don't think it's a wast of energy to provide useful features to users. 
  It is a mistake to assume that resources in FOSS projects are 
fungible.  Just because people are prevented from working on kdelibs in 
4.8, doesn't mean more resources are available for KDE Frameworks.

> ---
>
> Now while I can empathize with those who wish to see their feature
> upstream as fast as possible, I fear Kevin and others do not see the
> pot. struggles of opening kdelibs.

kdelibs is already open.  The packagekit/apper change that Kevin 
discussed is in Fedora.  I'm sure Kubuntu will pick it up in order to 
make the latest Apper work.  It's going to happen, the only question is 
how coordinated it's going to be.

> KDE frameworks is essentially the approach to segregate kdelibs, what
> is hard enough on a frozen object but completely impossible on a
> "living" being - at least under the conditions of KDE development.
>
> To do so it would be necessary to intercept each and every feature
> commit to kdelibs, inspect, channel, sometimes stall and ultimately
> merge it to KDE frameworks.
> While adding a second parameter to a function is a nobrainer, adding
> complete classes will require to rethink the constellation of
> the frameworks and that should happen as early as possible, regarding
> both, frameworks and the new feature.
>
> I am sorry to say, the open structure of KDE is a great thing, but it
> completely lacks the discipline and hierarchy for such (see Valentine's
> SecretService merge - no offense, i've don worse) and I doubt anyone
> wanted to buy in /that/ at all (because it'll kill the fun part)
>
> (As a sidenote: I also slightly fail to understand the prohibition to
> implement the new feature in the client(s) and keep it there until the
> final move to KDE frameworks, but that's not important)

I fail to understand it either (I'm not ignorant of the plan, I don't 
need it explained to me, I just don't think the case to not allow people 
willing to work on features in 4.8 is at all compelling).

> ---
>
> On the other hand, this is free Software, written by many free
> individuals - for free and personal joy.
>
> This makes it impossible to just say: "kdelibs is frozen" and that's it.
>
> If the pressure to break the freeze grows to strong, people and
> esp. distros /will/ work around that, with the option for
> the unfortunate implications mentioned in the first paragraph.
>
> One simply cannot command or forbid things and force people to apply to
> that rules.
> Instead one has to take a soft path [1], because getting things done
> right is not invalidated by peoples minds.

It's already happening, so the real question is how to minimize the impact.

...

Scott K