Bug 182318

Summary:	There needs to be an additional bug severity for missing KDE3 functionality
Product:	[Websites] bugs.kde.org	Reporter:	Mathew Hennessy <kdebugs>
Component:	general	Assignee:	Matt Rogers <mattr>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	grundleborg
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Mathew Hennessy 2009-01-29 16:35:18 UTC

Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Fedora RPMs

Sweeping missing KDE3 functionality into 'wishlist' is frustrating for 3.5 users who are increasingly being pushed into KDE4 by distros, and finding that KDE4 is missing functionality they've come to expect from 3.5 .  Granted, crashes and other bugs should take precedence, but dumping KDE3 functionality requests onto "whenever we feel like getting around to it" is weak.  

Perhaps an additional severity, such as 'missingfeature' or 'featureparity' would help to address this issue better.

As a user, I expect everything in core KDE packages from 3.5 to be there in KDE4, and anything that isn't should take priority over wishlisty extra brand new features...

Comment 1 George Goldberg 2009-01-29 17:19:55 UTC

I agree that it would be useful to have a way of indicating reports that are feature-regressions from KDE 3 days, but perhaps it would be better to use a Keyword rather than a severity (although I'm not entirely certain that it shouldn't be a severity).

Matt, what do you think would be more accurate/appropriate?

Comment 2 Matt Rogers 2009-01-29 17:28:22 UTC

I don't necessarily agree that this is a good thing. The KDE4 versions of the apps have, in some cases, largely different goals and therefore won't achieve and don't intend to achieve feature parity with KDE 3.5. Also, while I'm sure the reports of functionality that is missing in KDE4 from KDE3 are appreciated, it should be up to the development team to prioritize their wishlist/feature request items as they see fit. 

So, long story short, let's leave it up to the developers of a product in bugzilla to determine how they want to handle requests regarding feature parity from KDE3 to KDE4.

Comment 3 George Goldberg 2009-01-29 17:35:53 UTC

So, in other words, it should be a Keyword (so that it is indicated, but can be interpreted by the developers of each application in whatever way they chose). Does this sound reasonable?

Comment 4 Mathew Hennessy 2009-01-29 18:00:01 UTC

Sounds reasonable, though I would add that if a feature is to be changed or deleted, it's fair to put that into documentation as changes from KDE3 to KDE4, and have an explanation why (and pointers to any new functionality that serves as a replacement)..  For example, if something is removed because of security concerns (such as easy-selfsigned-cert-acceptance in firefox3) there should be some documentation of that.

Otherwise you're basically stripping away things that KDE3 folks expect, and the reasons don't make any sense..

Here's an example: Konsole 'send all input' right-click on konsole tab went away.  It was replaced by a better mechanism, but it was frustrating having to go and find it.  It would have been very helpful to have a "migrating from KDE3?" document to consult, not sure where such a thing is...