On Wed, Nov 16, 2011 at 11:31 AM, Aaron J. Seigo <[email protected]> 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.
