> Hi Arjen,
>
> I think the typical way one gets deeply involved with gfortran
> development is as follows:
>
> 1. One starts using it and finds a bug/missing feature, which one
> reports
> 2. One starts building gfortran oneself
> 3. One creates a small, simple patch, e.g. for a trivial bug or for
> the documentation
> 4. One gets involved in fixing bugs
> 5. One starts writting bigger patches & reviews other patches
> 6. The steering committee appoints one as maintainer
> (7. All the programs one uses work and one gets other work to do and
> thus one mostly stops gfortran development)
>
> Any help at either stage is welcome (though (7) less so ;-) and there
> are several contributers which restrict themselves to finding bugs,
> triaging bugs and testing patches (though I still have the hope some
> of them will start writing patches themselves).
>
> В * * *
>
> To get involved:
>
> a) Very important is that bugs are reported. If you know a code which
> is standard Fortran 95 and it does not work - report it; if possible
> try to reduce the source code to the smallest possible which still
> reproduces the problem (for proprietary code you need to do so). Same
> for all internal compiler errors. Bug reports and feature requests for
> Fortran 2003, (common) vendor extensions, better diagnostics etc. are
> also welcome but have (naturally) a lower priority [for instance we
> already know that CLASS is missing and we plan to add it in 4.5, but
> better a bug report/feature request more than one too little].
>
> Even though gfortran has a rather large test suite (94192 lines) and
> it is regularly checked against some big real-world codes, benchmark
> codes (CPU Spec, Polyhedron) and Fortran test suites, there are and
> will be always old and new bugs (regressions), including performance
> regressions. Thus doing regular tests with your most favoured codes or
> the most wicked corner cases you can can up with are helpful.
>
> Note 1: Not all bugs reported to c.l.f are found and entered in
> Bugzilla; it would be nice if users reading c.l.f could also check
> whether a bug report exists. If you don't like Bugzilla or are unsure,
> whether to fill a bug, you can also write to the fortran insert at
> sign
gcc.gnu.org mailing list.
>
> Note 2: It makes sense to use the latest developer release (currently
> 4.4, which is in the bug fixing stage (Stage 3) or the latest released
> version (currently
4.3.x). Regressions and important bugs (with fixed
> by simple patches) are fixed in
4.3.x and in 4.4, all other bugs will
> only be fixed in 4.4. Version 4.2 or older are effectively not
> maintained.
>
> Especially if you have access to a non-default system, testing there
> (and debugging failures) is especially appreciated as most of the
> developers are only using x86 and x86-64 Linux systems, though we have
> some regular MacOS PowerPC and Windows users and the test suite is run
> on all kind of systems. (However, we lack developers with Windows
> expertise, which is an important platform for gfortran in terms of
> usage and a bit neglected.)
>
