Decision making processes in KDE (?)

[Matthias Welwarsky]

--Boundary-02=_gee69JHMb2IfL4D
Content-Type: text/plain;
  charset="windows-1252"
Content-Transfer-Encoding: 7bit
Content-Description: signed data
Content-Disposition: inline

On Sunday 01 December 2002 02:27, Zack Rusin wrote:
> On Saturday 30 November 2002 11:35, Matthias Welwarsky wrote:
> > Conclusion: KDE only worked up to now because there were nearly no
> > conflicts that needed to be settled involving more than a few people.
> > Conflicts involving larger groups were settled by divine intervention
> > (Coolo or Waldo or someone just did what deemed the correct thing to
> > do for him), or were not settled at all.
> >
> > Recent example: KMail maintainership. This conflict could not be
> > resolved by technical means. The group was to large to base arguments
> > on common sense. So, it was _not_ settled at all. It was delayed into
> > the future and has reemerged now that the pressure of the release
> > cycle is gone.
>
> Excuse me? You just couldn't pick a worse example :) In the conflict
> between Don and Michael both parties had very good arguments. Don was
> completely ready to fork at any moment. Now you're saying that it would
> be good if people not related to KMail development would come by and
> say "Hey, Don we do not like what you're doing and we have to remove
> your KDE CVS access". 

Hm? I was not saying this. All I was saying is that the dispute on KMail 
maintainership could not be settled by technical means or common sense, then 
Dirk stepped in and "forced" the parties to cooperate. He could only do this 
because the release date was due. 

> The fact that the problem "reemerged" as you put it, had nothing to do
> with the fact that it wasn't resolved. Michael stopped being the
> maintainer. We needed a new maintainer. 

This is an interesting view. Michael stopped being the maintainer, but why did 
he do so? My personal opinion is that he was just sick of fighting Don ;)
This excerpt is from his mail to kde-core-devel:
----
Additionally I'm tired of having regularely to fight with other people. Either
with unthankful users that believe to have a right to have all their support
questions answered in private mail by the maintainer or the feature they
requested implemented immediately or with developers that can't live with a
patch of them being rejected.
----

> All KMail developers agreed that Ingo should be the maintainer.
> Also in many of those emails one can spot smileys and notice the
> overall better atmosphere following our replies to each other. Ingo
> showed that he's going to be a great leader by allowing Don to be the
> co-maintainer and making sure KMail is not going to be forked and
> that's it.

I'm rather sure that Don has quite his own view on who's the maintainer of 
KMail, but this does not deserve to be detailed on this list. Ingo also gave 
in to Don because he didn't want KMail to be forked, read this excerpt from 
Ingos Mail to kde-core-devel about the status of KMail maintainership:
---
After discussing this issue a little bit with Don in a short private
mail exchange and proposing an alternative to him that he turned down I
accept this offer since any other solution would put KMail in danger of
a fork. Don already proved that he wouldn't hesitate a second to fork
KMail. I'm a little bit disappointed that he can't accept what
apparently all other KMail core developers agree on (Thanks, guys!).
Whatever. Now that this issue has been resolved we can go back to
work.
---

So, Don has his way because his status is commonly agreed upon among the KMail 
developers or because of the constant threat of a fork?

On a sidenote, be sure that I don't want to attack Don. This is just an 
example on how conflicts are (not) arbitrated in KDE. I'm quite sure that we 
will see more things like this all around KMail development. 

> What we regulate? I think it's quite simple, we regulate when an app in
> our CVS goes against
> http://developer.kde.org/documentation/licensing/policy.html . We email
> the author saying that it's a requirement that his/hers app obeys those
> rules and there's no exceptions for it. If the author refuses his app
> is removed from the CVS and possible, depending on the author behavior
> his/hers account is removed. Period.

Yes, but the licensing policy is a technical document. You can very easily 
check an application against this document and act accordingly. It is also a 
commonly approved document, which makes it easy to execute it.

> Now the question is how do we protect our CVS users. I'd propose
> imitating court rules here. (Stay with me here :) )

[details deleted]

This is astonishingly similar to what I had in mind myself. Just replace 
"release coordinator" with "group of KDE core people appointed by the 
rivaling parties".

regards,
	matze

-- 
Matthias Welwarsky
Fachschaft Informatik FH Darmstadt
Email: matze@stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"

--Boundary-02=_gee69JHMb2IfL4D
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA96eegANO+fpRuZ2IRAtjeAJ9fpHlHrn/bsFm8bSU1BAWzriopFgCgzobe
1rsu9x4sMpN3OVCoyBTF5H8=
=1wTK
-----END PGP SIGNATURE-----

--Boundary-02=_gee69JHMb2IfL4D--