Re: Proposed gfortran development branch

[dominiq at lps dot ens dot fr (Dominique Dhumieres)]

On Fri, 20 Mar 2009, Joseph S. Myers wrote:

> Maintainers of components of the compiler retain their usual discretion
> to decide which changes to the areas they maintain are safe at a
> particular development stage - bearing in mind the responsibility of
> everyone concerned not to delay the branch or the start of Stage 1 unduly
> by making changes causing P1 regressions.

In my opinion, this makes clear that the present frozen state of gfortran 
is due to a deliberate choice of the gfortran maintainers. Let me say that 
I don't understand this choice since gfortran regressions will never be P1.

On Sat, 21 Mar 2009, Paul Richard Thomas wrote:

> Since my enthusiastic, immediate response, I have been getting cold feet
> about a development branch for all pending patches.  I have a load of
> "F95" patches that are ready to go that are not really suited to such
> treatment; largely on the grounds that they should be tested in the field
> by having been committed to mainline.  On the other hand, the "same file
> compilation" and the memory check patches could usefully go to the
> development branch for checking out by gfortran developers.  Similarly,
> the array descriptor work should go to a development branch....  but
> should it be the same one?
> 
> Thus, I would ideally like to be able to commit as many as possible of
> the really safe patches to trunk (38915, 7, 8 and, possibly, 38538).
> However, I do recognise the problem of disturbing a very stable release.
> What to do?

In my opinion "a very stable release" is a useless metric: doing nothing
will always give "a very stable release", for what?  Without the work of
the gfortran maintainers, with many trials and errors, gfortran 4.1.0 would
have been "a very stable release", would have it make gfortran a usable f95
compiler?

Once changes has been reviewed and regtested, I fully agree with Paul that
"they should be tested in the field by having been committed to mainline."
Delaying the commits won't fix the latent bugs, only delay their finding.

Last comment: http://gcc.gnu.org/wiki/GFortranPatchTracker should probably 
be renamed to something such as "Pending patches" and updated.

Cheers

Dominique