[fpc-devel] Alternative parsers

[Marco van de Voort]

In our previous episode, Alexander Klenin said:
> > not cooperating, and just throw raw patches to core, and then trying to
> > blackmail core into accepting them by raising noise on the maillists)
> 
> To be honest, I was responsible for at least half the noise in this thread.
> Also, what do you mean by "raw" patches?

The diffs of his working repo, with unnecessarily refactoring and formatting
removed so that it makes the job on the reviewer easy.

> Do you want a "cooking" model similar to the one used in git.git development?
> That would be good, but practically impossible to do using svn.
> 
> > The first principle of working in a team is assuming that all code is good,
> > unless proven otherwise.
> 
> Don't you violate this principle by assuming Hans-Peter's code is bad?

I didn't assume, I looked at it. It's hard not to, since his commit messages
roll over the IRC channel.

I never expected Hans-Peter to really come up with something in the first
try, but I more or less expected it would be a scheme like:

1. A new developer first wilde ambitions plan fails because ideas are too
unfocussed, on a too big scale, too idealistic and requiring too much up
front commitment.

2. The first effort fails, but parts of it that do work are cleaned up and
integrated. The developer keeps working and from time to time, finds some
subsystem he is interested in, starts maintaining it and gaining experience.

3. After an year, or two, he offers a patch with a certain rewrite or a
feature branch that covers the more realistic part of his original ideas,
and it gets incorporated, and he stays maitnaining it.


The problem with Hans-Peter is that 1 happened more or less, but the second
part didn't because he didn't want to compromise and stick to the FPC core
teams rules. Moreover the plans were awfully unfocussed, and tried to
delegate quite some of the work and responsibility to core beforehand. (by
requiring every step to be merged in before he had anything working, based
on just principles. Worse he didn't even make it easy for Core to merge it)

IMHO, he should have toned down a bit, and continued working in a branch to
achieve something tangible with as minimal possible intrusion. 

That's how you get things done. Not by letting your self get dragged into
all kinds of refactorings because "otherwise I can't carry out my real
plans".  In short : "Don't blame the tools, work with what you have to do
the job".

One can hardly expect core to radically change the philosophy of the project
for every would-be developer that thinks he has an idea.

People keep blaming core in these threads because they are supposed to be
against HP's changes.  While that may be true, such meanings can change if
you show something tangible, preferably if it can be incorporated easily.
And that has happened before. Moreover, opinions differe with time.