-28

kde quality is poor
compared to commercial-quality products, KDE is

KDE _ _ _ _ _ | _ commercial-quality
1.0-beta _ _ _ | _ 1.0-milestone-1
1.0-rc _ _ _ _ | _ 1.0-beta
1.0 _ _ _ _ _ | _ 1.0-rc
1.1 _ _ _ _ _ | _ 1.0-rc1
not exist! _ _ | _ 1.0
not exist! _ _ | _ 1.1

My idea is to improve this situation
for the full version should be assigned the task
current determinant for release a new version is the date, but should be completed assigned task

Now, we have a lot of critical bugs with long age like
protection rewiting settings -> brainstorm.php#idea62573

I undestand, that KDE is community of free users who want to codding a new featues because debugging is boring
Maybe there is a chance to improve the situation?

Great idea!!

[/IRONY]

The way I see your idea, it just says "Make KDE better" instead of actually proposing a solution. If you don't have a viable solution to propose, this idea may not make it to the "valid" section.

As was said above, "KDE isn't good" isn't a valid problem. ??_??

Madman wrote:As was said above, "KDE isn't good" isn't a valid problem. ??_??

The problem isn't all what makes up an idea. "XYZ sucks" is too generic and it doesn't qualify as an "idea" rather becomes a rant. As the idea submitting guidelines say (brainstorm.php#idea35581), each idea should have a proposition and a solution, and the latter is missing here.

sayakb wrote:

Madman wrote:As was said above, "KDE isn't good" isn't a valid problem.quote]

The problem isn't all what makes up an idea.

Well yes, but this idea was obviously posted in order to solve a problem. The problem itself is kinda invalid.

Anyway, enough with the technicalities. KDE sucks like this idea sucks. (Well, hopefully not...)

Madman wrote:The problem itself is kinda invalid.

True.

Madman wrote:KDE sucks like this idea sucks. (Well, hopefully not...)

Heh sure so "as said above":

Great idea!!

[/IRONY]

My idea is to change release determinant - not based on date but on completed tasks.
This should improve quality

I personally don't think changing a tag alone will improve quality.

For example, as this topic indicates, KDE needs more contributors who can maintain the apps. And when you change a determinant to a higher level, you will also need more manpower to achieve that, which is something that probably can't be just proposed..

Anyway, approved. This is something that is 100% dependent on developer consent imho.

I am not confident that a feature based release cycle would lead to better implementations of said features.

The time based cycle has the advantage that it is more predictable which is important for downstream (e.g. the Linux distributors).

Actually KDE's procedure is a kind of hybrid: only completed features get into a release and they have to be ready months before the actual release date.

>kde quality is poor

10 you(!like(it))
20 you(!use(it))