[fpc-devel] Alternative parsers

[Graeme Geldenhuys]

Op 2010-10-19 10:49, Martin Schreiber het geskryf:
>
> FPC is used in *production*!

I agree, but this shouldn't prevent enhancements, forward thinking and
innovation.


> We can't accept experimental changes of the compiler architecture in 
> trunk.

For production use, and for "stability", that is what the releases are for.
Stick to those then. Trunk is a development branch, you should *not* be
using in for production work, because it is unstable, and can break in any
commit.

Like I've said a million times before, the management of the FPC project
seems a bit off (sorry if this offends some of you, don't take it
personally). Hardly anybody looks at the various branches, so to truly test
something new, a workflow similar to the git.git repository needs to be
adopted. Feature branches are used, a experimental/development branch
exists where feature branches are merged together. This is the branch most
would test (in terms of SubVersion speak, consider this Trunk), and
inherently test those features too. Features in this branch are not
guaranteed to make it into the release branch, but importantly, it gives
them a time to shine and played with. A more stable branch should exist.
This contains features that have been tried and tested, and got promoted to
the next level. It is this branch that is used to cut new releases from. At
that point "fixes" branches could be cut from the release branch. Fixes
applied to the fixes branch can be merged back into the stable branch and
vice-versa.

If svn is not up to the job (I'm not saying it is), or seems like to much
work using svn, then the SubVersion software is the wrong tool for the job,
because what I described above is done with very little effort using Git.
In the git.git repository, all this is managed by a single person in his
spare time, and the git development is a 1000x faster than FPC's, with
hundreds of contributors.


> Also refactoring because of personal preferences, aesthetics or 
> new design patterns or paradigms must be handled very carefully

Yes, there goal is normally to make code more manageable and easier
understood by others - indirectly making contributions easier.


> There is a big 
> danger of degrading the stability by such changes which are not planned 
> by the core developers.

That is what unit testing frameworks where designed for. Unit test the
compiler code, so there is no surprises and no guessing required to know if
something broke something else or not. FPC has some tests, but I have no
idea how extensive they are. Last time I looked at the various tests
results published on the web (I can't remember that URL of the top of my
head), the outcome looks rather sad - with many many failed tests. I'm not
sure of all those failures were false negatives though.



Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net:8080/fpgui/