[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Fork of KDE4/Qt3?
From:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2008-06-10 11:56:48
Message-ID: 200806101357.02235.kevin.krammer () gmx ! at
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 10 June 2008, Mark A. Taff wrote:
> On Monday 09 June 2008 17:42:42 Christopher Blauvelt wrote:
> > Then write it, or pay someone to do it.
>
> Which is *exactly* what the topic of this thread is.  Should we fork KDE?
> Or Kdesktop? Or fix Plasma?

Well, I think the topic orginally was about continuing to developer KDE3 
feature wise as a separate project.
Up to this point most people have come to the conclusion that working on 
improving KDE4 is a more realistic approach.

> Of course, you are only joking.  I seriously doubt kcd would allow us to
> start screwing with Plasma to reimplement missing desktop features.  The
> first time we changed something in a way that didn't fit into the Plasma
> devs idea of the Right-Way, my svn credentials would probably be yanked
> straight away.

Since I am not involved with this part of the KDE technology stack this could 
be wrong, but my understanding is that one does not have to change Plasma 
core technology but that any kind of user interface functionality or behavior 
can be implemented as a loadable component of some sort.

> Even if I had the money, which I don't (though I have traditionally been a
> financial supporter of some KDE software), I would not be permitted to pay
> someone to implement what I wanted if what I wanted happened to conflict
> with Aaron's roadmap for Plasma.
>
> The fact is, "write it or pay someone to do it" only applies *after* you
> have won the debate, at least within the confines of a software project.

Actually no.
Especially features developed on contract basis are almost always done in a 
branch, so that the contractor can concentrate on delivering the requested 
items and not having to deal with probably conflicting changes to the main 
line code.

Even if a competing feature set would require changes to some technology core, 
its development would proceed unharmed in its branch.
Once it is actually possible to evaluate the impact of proposed changes, 
chances are a lot higher to find agreement between involved parties.

Nobody will revoke commit access for anyone even for highly experiemental work 
as long as it is done properly.
Any development that requires deeper changes on already existing code is done 
this way, e.g. Solid and Phonon developers had their own branches of kdelibs 
until they had stabilized their respective changes to that code base.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]