Posted by: Anonymous
[ip: 216.50.65.6]
on July 16, 2008 10:51 PM
The article starts off with "KDE 4 problems highlight shift from community users to consumers" which is wrong. The people that have adopted KDE is the same community that has always been first adopters. All the musing is then wrong.
Then the article says:
This situation leaves developers of large and popular projects with a dilemma. On the one hand, most free software developers want to add and enhance features. At times, too, they want to overhaul the code to make it more efficient. Their pride and interest in their work demands that they improve it, yet this desire may run counter to the desires of their most vocal users...So what is the solution? Introducing changes at a slower rate, so that users are not overwhelmed? Involving users more closely with the development process or communicating goals more clearly?
The problem is that KDE had an itchy release finger and pulled the trigger a full 6 months, if not a year before it was ready. The reason why it wasn't ready was that Plasma was not ready, and all bets were on plasma.
Here's what should have happened:
KDE Port to Qt 4. Call this "alpha" and put all developers on notice to adjust to the new API.
Reconcile and package the ports of all critical apps identified for porting. Call this "beta".
Regression test and fix. Call this "rc"
Release. Call this "4.0"
Meanwhile, plasma development can be done in paralell. In fact, it should have because the QGraphicsView which plasma relies on wasn't in the original Qt version used by KDE. This should have been an obvious decision to not rely on anythign Plasma for release. Its a no-brainer. Then, for 4.1 start introducing plasma components to replace the old KDE 3.5 style components.
So, between 4.0 and 4.1, release Plasma as "alpha"
Develop Plasma versions of apps, giving notice that plasma is seeking feedback during their port to plasma.
Release 4.1 "alpha" and Plasma "beta" when all core Plasma apps are developed
Release 4.1 "beta" when developers have gotten back to you on plasma issues, and those issues are deferred or fixed.
Release 4.1 "rc" when plasma and plasmoids churn is sufficiently low
Relase 4.1, with plasma, plasmoids.
There is nothing in here to dictate that plasma or plasmoid development can not be concurrent to 4.0. The only think limited in 4.0 would have been to not have any reliance on plasma. This would have been a much less painful iterative approach.
Learn about Linux
Download Linux
Get Linux help
The article is as flawed as the KDE 4 release
Posted by: Anonymous [ip: 216.50.65.6] on July 16, 2008 10:51 PMThen the article says:
This situation leaves developers of large and popular projects with a dilemma. On the one hand, most free software developers want to add and enhance features. At times, too, they want to overhaul the code to make it more efficient. Their pride and interest in their work demands that they improve it, yet this desire may run counter to the desires of their most vocal users...So what is the solution? Introducing changes at a slower rate, so that users are not overwhelmed? Involving users more closely with the development process or communicating goals more clearly?
The problem is that KDE had an itchy release finger and pulled the trigger a full 6 months, if not a year before it was ready. The reason why it wasn't ready was that Plasma was not ready, and all bets were on plasma.
Here's what should have happened:
KDE Port to Qt 4. Call this "alpha" and put all developers on notice to adjust to the new API.
Reconcile and package the ports of all critical apps identified for porting. Call this "beta".
Regression test and fix. Call this "rc"
Release. Call this "4.0"
Meanwhile, plasma development can be done in paralell. In fact, it should have because the QGraphicsView which plasma relies on wasn't in the original Qt version used by KDE. This should have been an obvious decision to not rely on anythign Plasma for release. Its a no-brainer. Then, for 4.1 start introducing plasma components to replace the old KDE 3.5 style components.
So, between 4.0 and 4.1, release Plasma as "alpha"
Develop Plasma versions of apps, giving notice that plasma is seeking feedback during their port to plasma.
Release 4.1 "alpha" and Plasma "beta" when all core Plasma apps are developed
Release 4.1 "beta" when developers have gotten back to you on plasma issues, and those issues are deferred or fixed.
Release 4.1 "rc" when plasma and plasmoids churn is sufficiently low
Relase 4.1, with plasma, plasmoids.
There is nothing in here to dictate that plasma or plasmoid development can not be concurrent to 4.0. The only think limited in 4.0 would have been to not have any reliance on plasma. This would have been a much less painful iterative approach.
#