I've been pondering the question of "when should we backport features?" It's fashionable right now to backport features in Plasma (and, I imagine, other applications) from the development track to stable releases and then include those stable releases plus the backported code from unstable branches to the general user base.
It has been shown that this leads to bugs since the features backported are not always completed or been properly QA'd (that's the meaning of a "development branch"). It also diminishes the goals of the upstream development team by changing the timing and combination of features provided (which can have morale diminishing effects of "stealing their thunder"). It also exposes users to unnecessary risk: what happens if we change how the configuration is stored and retrieved for any given feature? What happens if we change how the feature works, or even withdraw the feature from a release due to scheduling?
There is a reason we have release cycles, and backporting here and there circumvents all of those reasons. It's a bit ironic that some doing the backporting are also involved in planning releases and understand those reasons, implying that it's good enough for upstream but not downstream.
Of course Free software is great because it lets you do whatever you want (within the bounds of that license). Some KDE distributors see good reasons in doing these backports: they want to support KDE 4.1 for a longer period of time and their user base demands a certain feature that is only available in the next release after 4.1. Or they don't have flexible release schedules and so can't wait for 4.2 or they have a policy of not offering upgrades such as 4.2 for a release based on 4.1 (a form of self-imposed inflexibility). Or they simply want to show off as being "better than the other KDE teams" while others then prove they can "keep up". There are numerous reasons for backporting, some better than others.
It remains a judgment call in all cases, however. I urge those doing the backporting to use their judgment wisely and consider both their users and upstream developers in the process.
One unfortunate result of this backporting fad is that every time we do anything interesting in Plasma these days we get requests from someone to backport it, as if that was always easy and came with no downside. It's getting a bit ridiculous and completely runs counter to the idea of release and testing processes, and puts us in the Plasma team in an uncomfortable position of saying "No" to questions (and people) we should never have to be confronted with.
There is a middle ground, a balance point to be found. Right now I don't think we're there, though with a bit of thought and care we can reach it.
What do you think is a good reason or motivation to backport features that are in a development branch back to a stable branch?