Star The Critics are Wrong: KDE 4 Doesn't Need a Fork
Linked by David Adams on Wed 2nd Jul 2008 16:11 UTC, submitted by elsewhere
KDE "After the recent release KDE 4.1 beta 2 and openSUSE 11 with KDE 4.0.4, some critics have been especially vocal in expressing their displeasure with the KDE 4 user interface paradigms. The debate has grown increasingly caustic as critics and supporters engage in a war of words over the technology. The controversy has escalated to the point where some users are now advocating a fork in order to move forward the old KDE 3.5 UI paradigms. As an observer who has closely studied each new release of KDE 4, I'm convinced that the fork rhetoric is an absurdly unproductive direction for this debate."
E-mail Print r 5   98 Comment(s) http://osne.ws/fe8
Permalink for comment 321278
To read all comments associated with this story, please click here.
aseigo
Member since:
2005-07-06

Yes the menu which with a single click still does not provide all functionality of the previous (such as easy access to key bindings).


it does in 4.1.

Semantics and smart quips do not change the fact that the default menu option is an important choice and a branch or release that changes the default is a fork, however minor of one.


then every distro release made of kde or gnome ever is a fork. in which case, i'm unconcerned and this shouldn't be a matter for a rash of public news.

"(adding features already stated to be added has got to be the lamest reason for forking rather than getting involved i've ever heard =)



As I am well aware. However given your penchant for marking bugs that you do not agree with as "Won't Fix" "

because some of the reports are, well, not going to be addressed. compare to the number of reports that are. the reports that get marked with WONTFIX by me are less probably than 1% of the reports that are either accepted or fixed.

if i implemented every single request without exception, things would be an awful mess.

I mention them as inequities of the current release?


if you continue to harass me about things that have already been fixed, however, it won't be very impressive. if you say, "but we need $FOO" and i say "$FOO is in 4.1, coming out next month" and then you say "but we don't have $FOO" again, what do you think?

EDIT: and they most definitely are design decisions. Priorities and ordering features to implement are design decisions. Software is mutable, but a decision to include or exclude a feature from a release is a design decision and it does impact the usability for some.


to me these are logistical decisions: which features to implement in which order. they follow from design, but are hardly strategic decisions.

My main contention is the cashew, I fixed that in my own code since you refuse to accept it as a bug (which if I am not mistaken would be in the top 20 if not marked won't fix).


i refuse to accept the request as requested. and i've explained why: the design as put forth in that bug report is quite simply wrong. i've noted in the report (and elsewhere) repeatedly how the design of plasma *actually* works.

if you stop fighting the design and start flowing with it, you'll find you get everything you want, including no cashew.

but i'm not going to let those who are not cognizant of the design screw it up. or do you expect the kernel developers, rdbms developers, apache developers, etc, etc to all implement the algorithms you pitch them for things you evidently aren't familiar with? it's exactly the same thing.

For that matter I am working on allowing menu to be right click in my spare time.


if you communicate with the project (panel-devel at kde dot org) your work could benefit others. up to you, of course, it's your time and patches =)

And thank you so much for being selective in what you comment on. I would hate for you to acknowledge that waiting till 4.2-4.4 was part of the very comment you are being derisive of.


ok, so let me address the 4.2-4.4 issue directly: if you fork things and take it off in that direction, you're pretty much wasting your effort. had the Suse guys written their panel moving patch in a way that made sense for upstream inclusion, 4.0 would have it. replicate this for every feature you want that we have on our roadmap.

and yes, i explained to them what would make sense for upstream inclusion. instead i ended up writing it from scratch for 4.1. that seems like a waste of their effort and unfortunate for everyone who had to wait an extra 4 months to see it in 4.1.

If a feature is not in the current release and a branch is made with distinct features (in the same repository or independently) it is a fork.


this is a rather strict definition of "fork", and generally not what is implied by the term.

If things go well the fork (or selective parts of it) will merge back into the main branch.


we do this all the time, yes.

It is minor features like this that makes forks valuable and I am sorry you are not of the mind to agree with me on that.


i have no issue with feature branches. but again, this is not what the word "fork" usually refers to.

I am not suggesting a coup from the KDE developers.


you do realize that that's what the term "fork" means in f/oss, right? hm.

I am merely suggesting if, once KDE4 development stabilizes, the features that are important to a group of people are not addressed a fork could be made to try these features and determine if they can not be put into KDE4 in a way that does not offend your sensibilities.


great. so here's some suggestions on how to do that: work in kde's svn where we can all see what's going on and make it easy to move patches around (e.g. into trunk/). communicate with the project so that we can attempt to work together. there's probably over a dozen active developers working on plasma on a nearly daily basis, so this communication would serve a lot of people.

if you are interested in working in this fashion, then get on panel-devel, we'll hook you up with an svn account and we can get down to hacking.

Reply Parent Bookmark Score: 3