[fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

Joost van der Sluis joost at cnoc.nl
Thu May 20 12:11:45 CEST 2010


On Thu, 2010-05-20 at 09:18 +0200, Helmut Hartl wrote:
> *EXPLICIT WARNING : "ACADEMIC VIEWPOINT"*
>   (this means worthless in practice :-)) (or I have read many books,
>   understood something and I am able to impress
> people with wrong mathematical proofs)

;) Nice.

To avoid the idea that something 'magical' is going on in the decision
process, maybe it's useful to clarify it somewhat. This is no official
statement, just an explanation how it in practice mostly works.

> 1) Who decides what comes into the base ?

First principle is that the one who implements something decides how it
is done. 

If there are conflicting interests, the core team decides. 

In this case (general rtl/fcl) that means that Michael, Marco (and I?)
decide. (The order of names is not randomly chosen) But in principle
we'll try to find an agreement. (As you can see now if you follow the
thread about it)

If the problem remains, other core people can also try to help to find a
solution. Finally Florian decides. He doesn't like to do that, but all
other members are likely to silently accept his decisions if he does. 

Again, this is nothing official, but I think that this is how it works. 

> 2) What If I am not able to respect this descision ?

You can write long mails to the mailinglist. If you see that no-one of
the core-teams answers them, I would say that you can better stop. As
your mails won't change anything.

> 3) Do I really need that red car toy on every case ? (eeh.. skip this)

I will. (skip)

> 4)  Is there a summary of the discussion that cares about more sides of 
> the problem ?
>    a) Performance Point ?
>    b) Memory Usage point ?
>    c) Embedded Usage ?
>    d) Crossplatform Usage ?
>    e) Compatibility ?

I think that the core-team are able to see all affects in these points.
And they will discuss some. And if that leads to a decision that is
technical inevitable, that eases the problem. (ie: a quick decision will
be made)

> 5) When is the RIGHT TIME to do that discussion ? (I certainly doubt 
> that it is now, 2.4.2)

It's discussed earlier in smaller groups. Now there was a slight remark
of someone that started the discussion. That's no problem. We aren't
discussing something that's related to 2.4.2. It could last a year (or
even years) before this is release-ready. Best time to discuss this
finally may be when we see each other in the real world. ;) (That's
pretty soon)

>      [To understand point 5 fully it may be good to be older than 25 
> years ;-)]
> 6) Am I speaking for my personal pleasure or am I able to consider the 
> points mentioned under 4 ?
> 7) Is it good to (often) block people who want to achieve something ?
> 8) Is there a solution who satisfies all parties to a certain degree or 
> are we really to dumb to find it ?
> 9) How to make such a change at the right time, and give more people the 
> ability to think about it
>      - or give them the time to not think - not test and live with the 
> consequences ?
> 
> The result should be a summary with pro's and con's and the ability to 
> take a proper and thought
> through decision.
> (Maybe a wiki page with a summary table and the ability to vote ?
> - If this would be a "democratic discussion" of course (see point 1) -

All good remarks. I think they are taken into consideration. But we
don't want that it costs too much time. Setting up a wiki, a vote system
etc. doesn't help us here.

Joost.




More information about the fpc-devel mailing list