The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: wow
by T. J. Brumfield on Wednesday 30/Apr/2008, @17:17
|
I think you're dead wrong. Openly praising bad ideas isn't helpful in the least.
I love KDE on the whole, and honestly, it looks like I'll be waiting until 4.2 to switch to the 4 series at the earliest now. I'm not upset that the KDE team is taking this direction, but I can see why others are. Everyone has said, "wait for KDE 4.1, and then you'll have the stable desktop with the common features people are looking for."
I was already worried since they are adding so many new features. New features do not go hand in hand with stability. Refactoring plasma at the last minute as well does not bode well for stability either.
This will blow up and give more negative PR to KDE. 4.0 got good press, but it also got bad press. If 4.1 isn't stable, it will only feed the cynics and haters more.
I think the real solution here is to move to something like git, where plasma breakage can happen in a seperate repository. Refactor it there, and then test some builds with it. If it works, then include it in 4.1, but what is happening now, is that people are breaking plasma in SVN, and talking about changing things up even more. Not to mention, the QT 4.4 changes have to be taken into consideration. I have little faith that KDE 4.1 will be more stable than KDE 4.0 at this point.
|
[
Reply To This | View ]
|
Re: wow
by Jonathan Thomas on Wednesday 30/Apr/2008, @17:52
|
From the Aseigoborg:
"There seems to be some concern amongst users about the massive surgery we did on libplasma this past month. The concern stems from the idea that these changes will work against the stabilization of libplasma and result in prolonging a "beta" quality to plasma itself.
It's important to first understand that these changes were planned, even before 4.0. We knew that "widgets on canvas" was coming and so we could eventually remove our own layouting and QWidget bridges at some point for something that was more robust and less of a hack. We also knew that being a first revision of a library API (application programmer's interface) that would see a lot of usage, it was highly likely that changes would come to be needed or wanted. It's nearly impossible to foretell exactly what will be used and required in such an API, and it's really unrealistic to hope that the first draft of the semantics in an API will be optimal any more than it is to expect the first draft of a novel to not need any editing and revising.
So before 4.0 came out I told everyone that libplasma would not be binary compatible between 4.0 and 4.1 so that we could reshape the API as needed to make it last longer. I told everyone that we'd be porting to widgets on canvas when we could begin using Qt 4.4. I told everyone that we'd be replacing the icons-on-desktop implementation with something more robust that offered access to the same features.
This was all known and planned for before 4.0 was released. None of them could be done in 4.0 for various reasons (such as Qt 4.4 not being available to us), and so we lived with various hacks and bodges.
Moving to the development of 4.1, we executed on these changes. Right now plasma is approximately as stable and in most areas a bit more featureful than what is in 4.0.4, even with all those backports we did to catch up the 4.0 branch. There are a few regressions that remain in the development tree right now, but they are disappearing with rapidity. But being able to finally see things happen that we always imagined, such as the device notifier expanding from an icon to the full view when dropped onto the desktop (aka "adjusting the visualization in response to the form factor"), is very rewarding to watch happen.
There has been one downside to the massive changes: it took time away from creating more new features. So some of the plasmoids I wanted to have working for 4.1 may not happen and get punted to 4.2 instead. Thankfully with all this work done, features that do get worked on from here out should be easier to accomplish than when working with the 4.0 API.
Thankfully we will not have to repeat this process again during the 4.x time frame. We will be able to move forward with keeping the API in place. We will add to it as needed, which isn't disruptive, while modifications such as these ones for 4.1 simply won't be on the table.
So if you are concerned about the recent changes made impacting stability, I thank you for your concern and empathize with how one could arrive at such a conclusion. Thankfully, these changes have been made specifically to answer your concerns, as well as mine, about stability and feature completeness both in 4.1 and beyond.
I hope that clears up a few things. If not, you may wish to track the betas and release candidates as they begin to appear near the end of May and see for yourself."
From: http://aseigo.blogspot.com/2008/04/on-recent-libplasma-changes.html
[My commentary now]
This API refactoring was planned even before 4.0, and 4.1 is still in the alpha stage; nowhere near to release. It's still another 3 months until final release, which is half the dev cycle, with the latter part of the cycle dedicated to bugfixing. And hey, right now, a mere week after tagging alpha1, Plasma is pretty much stable again. :)
|
[
Reply To This | View ]
|
Re: wow
by T. J. Brumfield on Wednesday 30/Apr/2008, @18:57
|
Plasma still has some serious breakage as of yesterday from what I understand.
Yet, the QT 4.4 changes were only the start. Now even more changes are planned. Even if they are finished soon, those changes are being made in the 4.1 trunk. The big problem with that, is that the 4.1 trunk isn't going to get much use for bug-testing and stabilization. We'll have 4.0.4, 4.0.5, etc, and if this rate of a new release every few weeks, we'll get tons of releases from the 4.0 branch. The 4.0 branch is becoming fairly stable. When 4.1 comes out, I fear it won't be as stable because of the changes. Even if you plan months in advance that you will eventually move and rewrite things, you need time to test, bug hunt, debug, etc.
|
[
Reply To This | View ]
|
Re: wow
by Sebastian Sauer on Wednesday 30/Apr/2008, @22:17
|
Well, we will also have 4.1.4, 4.1.5, etc. :)
btw, at the time KDE 3.0.0 was published I didn't switched to it either before 3.1.something cause things where not as stable as I would like to have them for my productive system.
Anyway, that KDE4 does follow the "release early, release often" rule is at the end an advantage for me. So, let's wait till 4.1.0 and probably even till 4.1.1, 4.1.2, etc. to see if KDE4 is finally stable enough for productive-systems like imho 3.1.x was :)
|
[
Reply To This | View ]
|
Re: wow
by Aaron Seigo on Thursday 01/May/2008, @22:16
|
a) where do you think the plasma features in 4.0 came from?
b) we have a deadline (the 20th) after which no new features can be added, giving us a forced period of testing, bug hunting, etc. to work on stabilization for 4.1.
|
[
Reply To This | View ]
|
Re: wow
by Anon Reloaded on Wednesday 30/Apr/2008, @22:20
|
"I think you're dead wrong. Openly praising bad ideas isn't helpful in the least."
Agreed.
"Everyone has said, "wait for KDE 4.1, and then you'll have the stable desktop with the common features people are looking for."
Then they've spoken out of turn, or are being very optimistic. You don't bring a huge departure like 4.0.0 into something near-perfect in just 6 months.
"Refactoring plasma at the last minute as well does not bode well for stability either"
"3 months before scheduled release" or "one month before feature freeze" or "just after half way through the dev cycle" (take your pick) != "at the last minute". Get some perspective, please.
"If 4.1 isn't stable, it will only feed the cynics and haters more."
Cynics and haters don't need feeding - if 4.1 rules everything in the world, they will continue to hate. And anyway, so what?
"I think the real solution here is to move to something like git, where plasma breakage can happen in a seperate repository. Refactor it there, and then test some builds with it."
Agreed - I'd like to see more and more devs using Git. It seems to be an excellent way of easily managing branches.
"If it works, then include it in 4.1"
Disagree - there's no point having another 6 months of third parties writing against outdated APIs. The new API should be in 4.1, full-stop. And it seems it does work, anyway, so the point is moot.
"but what is happening now, is that people are breaking plasma in SVN, and talking about changing things up even more."
Major changes happen in trunk three months before release! - sky is falling, etc. This is basically what is supposed to happen. Frankly, I'd be worried about the future of KDE if it weren't.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
