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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
