Leaving KMail development

[Bernhard Reiter]

I'm afraid that this problem will not get solved that easily.

You state that the criteria should be:
	- size of contribution between releases
	- quality of contribution (technical merits)

The question is who judges both to finally declare the maintainer.
If a person just needs to put in a lot of code lines and automatically
is selected as maintainer this would open up the possibilities for 
strange scenarious. It is a lot easier to come up with new feature
code, especially when not many people need that feature.
It is also harder to maintain stability in the code base with small changes
that just fix the bugs then to reorganise often.

You need to get the person which is best for the job, this also implies
criteria like
	- communication skills/ ability to moderate the development process
	- long term committment
	- ability to go for stability

A plain rule based on the size of the contribution will hardly work.

On Saturday 30 November 2002 03:52, Zack Rusin wrote:
> Our "release dude" should be the person who contributed the most before
> the last release. 

> Ingo is basically the person who made 3.1 possible.
> He contributed the most and fixed the by far the biggest number of bugs
> during the last year. He deserves to be our maintainer. Don contributed
> the most but only during the last three months or so.

From what I've seen Ingo's work in the last months
 is more valuable and more difficult than Don's. 
So I'm inclided to  think that Ingo contributed "more" than Don in the last three months or so.

> Basically this means that the KMail maintainer is always going to be the
> person who contributes the most. Simple as that.
> After each release we're going to pick the release dude. In fact it's
> not even going to be picking, as we'll all know who it's going to be
> before it happens (commits say it all). That also implies that the
> maintainer is picked only based on technical merits of his/hers work,
> and that a person can be the maintainer for as long as they want to and
> remain top contributors.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021202/1258a12c/attachment.sig>