Change the KDE procedures?

[Bernhard Reiter]

On Thursday 31 July 2003 12:38, Ralf Nolden wrote:
> On Donnerstag, 31. Juli 2003 12:22, Bernhard Reiter wrote:
> > On Thursday 31 July 2003 12:01, Ralf Nolden wrote:
> > > On Donnerstag, 31. Juli 2003 11:10, Bernhard Reiter wrote:
> > >
> > > I can only repeat: we're doing good stuff and we have our ways of doing
> > > so, because we do it for the fun of it (as one reason to do it, there
> > > are also others in many cases, but fun is definetly one of the highest
> > > ranking ones). Take the fun factor away and you'll loose a good part of
> > > the motivation of the volunteers.
> >
> > We also do some stuff suboptimal and this also it takes fun away
> > and looses motivation for the volenteers.
>
> You can't just claim it's all not working and too complicated. 

I didn't, but my statement above holds.
There are areas it can be improved.

> Besides: throughout the whole discussion I'm completely missing the point
> about *what* we're discussing anyway ? That KDE doesn't work for you or
> that it's too unstable ? That someone needs to have a say where someone is
> allowed to work on to not break the stability level ?

Reread my posts about the details, 
there have been several points.

Your last responses contained an message about:
"KDE is good, its' processes best, don't criticise."
I've put forward arguments why that attitude is not helpful for KDE.

> That's the level where you implicitely want a quality-control technical
> steering commitee.

If that is a question: No.
I understand why this is rightfully feared.

> Please help me understand what inside the KDE infrastructure you want to
> have changed where and how and, most importantly, why, and how you estimate
> what we would win compared to what we would loose.

I'm working the other way round, I've pointed to problems I see
and started analysing them. Several times I wrote down ideas
that might offer a path for improvement for this problem.
So I do not claim that I have a full comparision of possible options done.

One problematic area has been the mechanisms how developers
are forced to switch to the hottest versions of the whole group
of application, KDE libraries and QT. At least two other people also saw
this as an area of possible improvements.
For QT I was interested why not a bug-fix only release could have
been made as basis for KDE 3.2 development and fix for KDE 3.1.x.

It lead to the interesting point what is more important for KDE
and where the focus will be in the future: The core libraries
or the applications. My analysis went so far to say that the importance
of applications and their stability is growing for KDE.

We probably should split those discussions up 
and continue in their original threads or open up completely new ones.

> > > KDE's only entry level is
> > > the ability to read, write and think. Get the code, write a patch, send
> > > it in and you're part of the game - and you're as valuable as anyone
> > > else for the sake of the whole project.
> >
> > That is an illusion.
> > There are unwritten rules and hidden connections of power within KDE
> > like with any other human organisation of similiar size.
> > If you hide that, it only means that those rules and connections
> > are continously developing further without concious reflection.
>
> The unwritten rule is: get the job done. The way to do that is the rule
> above: write a patch and send it in.
>
> The written rules are on http://developer.kde.org, Stephan Kulow has the
> final say for KDE 3.2 as the one who is responsible for it.

It is good to see that you agree with me that there are already structures.
Of there are more than the ones that you've mentioned.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030731/fea59db3/attachment.bin>