>
> 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.)
>
> b) The documentation (
http://gcc.gnu.org/onlinedocs/gfortran/orhttp://gcc.gnu.org/onlinedocs/gfortran....) is in a quite good shape,
> but improvements are always possible. If you find an error, fill a bug
> report or better create a patch. But also enhancement patches are
> highly welcome.
>
> c) If you want to start programming the compiler (and have some [more
> or less basic] C knowledge): I think one can find some smaller
> projects as starting point, especially accepts-invalid and diagnostic
> bugs are usually not too difficult. Compared with the middle-end
> compiler work, programming the front end is usually not to difficult
> if one has found the way through the files. One essentially programs
> like normal; only in the later parts of the compilation process when
> the structure for the middle end is generated, it gets a bit more
> complicated.
>
> d) If you are really eager or you find a student who is, one can
> easily find bigger projects, which might also be funded by e.g. Google
> summer of code. (We had two students this year.) Though starting with
> (c) makes sense.
>
> Tobias
>
> PS: Note that for bigger patches, the Free Software Foundation (FSF)
> wants to have a copyright assignment,
cf.http://gcc.gnu.org/contribute.html#legal.
> Since paper-based letters are sent around, this might take a while.
> Thus if you think about contributing something bigger, you should
> write them as soon as possible.
