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

List:       kde-devel
Subject:    Re: Fork of KDE4/Qt3?
From:       "Mark A. Taff" <marktaff () comcast ! net>
Date:       2008-06-11 1:49:13
Message-ID: 200806101849.13203.marktaff () comcast ! net
[Download RAW message or body]

On Tuesday 10 June 2008 04:56:48 Kevin Krammer wrote:
> 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

Good point Kevin, like Jason.  Thanks.

--Mark
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]