[fpc-other] Fork

[Adem]

On 2010-10-22 02:50, Henry Vermaak wrote:
> 2010/10/21 Adem<listmember at letterboxes.org>:
>> On 2010-10-22 01:23, Henry Vermaak wrote:
>>
>> Did you notice the word 'promises'?
> Somehow you have to prove these "promises".
And, how exactly do you expect them to be proved? On paper?

>> Seriously, if this work was done more co-operatively with the fpc team, =
it
>> may have made it.  But I think it is too ambitious in the first place.  =
Some
>> people maintain patch quilts for ages before it makes it into the kernel,
>> for example.
>>
>> You make it sound like some of those religious orders where you have to
>> spend years of your life... just to prove your piety.
> I don't care what it "sounds" like to you, I'm pointing you to valid
> examples of real features that are complicated and that need to mature
> and to evolve, but most of all, need a lot of work before they can
> prove that they are worth anything.
OK. Let me take a step back.

You did say, above, "/Seriously, if this work was done more =

co-operatively with the fpc team, it may have made it./" which implies =

the approach was less than co-operative.

Fine, lest's look at that: Did you notice the response from the core =

that --/to the effect, that is/-- the code is 15 years mature and those =

who are familiar with it aren't prepared to see things shifted around.

Would you consider this as anything more than an invitation to do --at =

best-- cosmetic changes?

Or, let me ask it another way: How would you achieve =

co-operativetiveness --other than staying out?

You also said, above, "/But I think it is too ambitious in the first =

place./"

Interesting. Unless I am reading this completely wrong, you're not =

saying the direction/aim is wrong; just that it is 'too ambitious'.

I would have no qualms with that.

But, expect you to follow it up with something like "among that list, do =

this first and let's see how it works, then you could move on to this", =

but, definitely not (I hope) something sounding like "don't touch any of =

this in more than a couple of lines at a time".

Maybe you thought I sniped back, and hence didn't let you get to that =

point --if so, I am sorry--, but I personally would appreciate if you =

could do it now.
> To implement a complicated feature, you need to break down the
> implementation into a lot of patches to make it easy for review.
> People aren't going to start accepting your refactoring patches
> because you promise them that it'll be worth it in the long run.
What you said is of course true for incremental changes; but not so much =

for architectural ones that by necessity result in large changes.

Please take a look at the roadmap for FPC v3.0 here: =

http://mantis.freepascal.org/roadmap_page.php where it says "22 of 27 =

issue(s) resolved. Progress (81%).".

Great. A lot of hardwork is being done and all those doing it are busy.

But, where and how do you discuss things about the general direction, =

i.e. architecture questions?

And the reason is, everyone is too busy to spend time discussing things =

that are not immediately relevant to a bug or a certain ancillary feature.

-- =

Cheers,

Adem

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freepascal.org/lists/fpc-other/attachments/20101022/64210=
d49/attachment.htm