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

[Dawit A]

On Wed, Nov 16, 2011 at 11:31 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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.

First having a point of view on a subject is not necessarily fighting
against ones "own teammates". Be that as it may, simply stating that
new functionality cannot go into kdelibs-4.8 is simply an untainable
goal for one simple reason. There might be bug fixes that require a
new API and it has always been a long held kdelibs policy that adding
new API, so long as it is not BIC, is allowed for addressing a bug.
Unless of course we are now saying that bug fixes can wait too. I am
not saying that is the case for this discussion, but I just wanted to
point our that there are always exceptions to the rule.

As for my own case, the patch in bug# 54300, that seems to have been
the linchpin for this whole discussion, the idea of submitting it to
the frameworks branch only makes much less sense than committing it in
kdelibs-4.8 branch and forward porting the changes into the frameworks
branch. Why ? Simply because this particular patchset has two parts.
The one for kdelibs and another one for kde-baseapps. In order to
adhere to the rigid "no new features" in kdelibs-4.8 rule, one would
have to create and keep track of yet another branch in kde-basesapps.
Why is that better solution for such a trivial change ? Specially
since the patch does not change any API in kdelibs except for the
introduction of new strings. That just makes no sense to me. Instead
of having such a rigid rule, there needs to be some flexibility that
allows a case by case consideration for adding new features into
kdelibs-4.8.