On 11/15/2011 02:46 PM, Thomas Lübking wrote:
Am Tue, 15 Nov 2011 13:17:45 -0500
schrieb Scott Kitterman<k...@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
