From kde-devel  Tue Jun 10 11:56:48 2008
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: Tue, 10 Jun 2008 11:56:48 +0000
To: kde-devel
Subject: Re: Fork of KDE4/Qt3?
Message-Id: <200806101357.02235.kevin.krammer () gmx ! at>
X-MARC-Message: https://marc.info/?l=kde-devel&m=121309913531930
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============0127097119=="

--===============0127097119==
Content-Type: multipart/signed;
  boundary="nextPart1329673.YDS6XyqDga";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1329673.YDS6XyqDga
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
feature wise as a separate project.
Up to this point most people have come to the conclusion that working on=20
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 cou=
ld=20
be wrong, but my understanding is that one does not have to change Plasma=20
core technology but that any kind of user interface functionality or behavi=
or=20
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=
=20
branch, so that the contractor can concentrate on delivering the requested=
=20
items and not having to deal with probably conflicting changes to the main=
=20
line code.

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

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

Cheers,
Kevin

=2D-=20
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

--nextPart1329673.YDS6XyqDga
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBITmwOnKMhG6pzZJIRArOLAJ4i4wE2n1LnGGAVcjR+rjuzDwJ1TQCfXswS
7kT23IPcJmwwmNIenykAWmQ=
=pvTn
-----END PGP SIGNATURE-----

--nextPart1329673.YDS6XyqDga--

--===============0127097119==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0127097119==--