makefile -f Makefile.cvs aborts with compile_kpilot does not appear in AM_CONDITIONAL

Mickael Marchand marchand at
Sun Jan 18 18:28:57 GMT 2004

Hash: SHA1

Le Sunday 18 January 2004 18:11, Adriaan de Groot a écrit :
> [Once more unto the breach!]

> Mickael, I'm trying to understand - nay, figure out - what point it is you
> are trying to make. You've certainly managed to make Reinhold and me angry
sorry, that was not my intention.

> - but far from us to try to take away your right to free speech or commit
> bit. But cut down on the posturing, ok?
> On Sun, 18 Jan 2004, Mickael Marchand wrote:
> > that was not expressed that way yesterday. If you write a policy make it
> > at least clear enough.
> Is this your point? That the policy was not clear enough? We can work on
> that. Do you want a whole sub-paragraph 4b on punishments for people who
> break it?
it's one of the point yes, we have seen so far different commit policies 
appearing and it's clear to me that these are not clear enough.
but it's like writing a "law". It's a really hard work. but if you don't do 
it, you will certainly occur problem later because of the 

> > I just wanted to point out this situation so that people understands what
> > a "commit policy" also implies.
> Is this your point? That people have already broken the commit policy? We
> can work on that. No other part of KDE has ever worked with this kind of
> policy, it does take a little getting used to. What part of 4b applies? I
> think Danimo owes us a drink.
actually it was broken a few hours ago since kdepim was not compiling against 
kdelibs HEAD (which currently is 3.2.0).
I don't want to know where and why it did not compile. I was not able to get 
it installed, that's all. I thought the policy stated it had to compile.

> > I just blame the "policy" and the way things are going on and how it can
> > affect (in my opinion) development.
> Is this your point? That having a policy is bad? I don't think we can work
> on that. The PIM developers - you know, the guys that do the work while
> others snipe from the sidelines - have committed to working on kde-pim
> HEAD in a more professional manner. There's been a mistake made and fixed.
> The boiling oil is almost ready, and then the matter is resolved.
yes I think policies in this kind of project is bad, I really prefer 
discussion over "rules" and "laws".
the main reason is that KDE does not have a "tribunal" to find whether a law 
was broken or not which leads to long threads as we met many times already 
(especially in kdepim and kmail)

> Since I don't think all three of these can be your point concurrently
> (perhaps pick-any-two would work, but I don't feel like thinking it
> through right now), perhaps you should start a new thread "About the
> kde-pim policy" to state which one(s) it is.
if you want to have a policy it has to to be "very well" defined and clear. 
It's imho a really hard work to do for our kind of people. That's basically 
why I am opposed to it because it's not possible for us.
So having a non-complete policy leads to much trouble, much more than not 
having a policy.
For years, it worked without a real policy (maybe one was implied), people are 
free to commit when they know what they are doing (that's ambiguous :), if 
someone breaks something, he's responsible and has to fix it. I think that 
worked for long.
Anyway, I don't care much about kdepim, I just don't understand why kdepim has 
something more "special" that kdenetwork for example. 

as I don't plan any commit to kdepim there is no need for me to start another 
thread on it. We will just see how well it works.

Version: GnuPG v1.2.4 (GNU/Linux)


More information about the kde-core-devel mailing list