53 msgIncorrect bitfield aliasing with Tree SSA
5 msgResuming SPEC performance tracking at RedHat
62 msgSome thoughts about steerring commitee work
7 msgLibmudflap for sh-elf toolchain cannot access e...
34 msgRFC: Make dllimport/dllexport imply default vis...

Re: [patch,committed] Make Fortran maintainers ...
\ Brooks Moses (15 Jun 2007)
. \ Steve Kargl (15 Jun 2007)
. . \ Brooks Moses (15 Jun 2007)
. . . \ Steve Kargl (15 Jun 2007)
. . . . \ Kenneth Zadeck (15 Jun 2007)
. . . . . \ Brooks Moses (15 Jun 2007)
. . . . . \ Brooks Moses (15 Jun 2007)
. \ FX Coudert (15 Jun 2007)
. \ Tobias Schlüter (15 Jun 2007)
. . \ Diego Novillo (15 Jun 2007)

1 msgRFA: (dataflow?) testsuite regression since las...
10 msgPlease fork soft-fp from libc
3 msgHow to submit Intel BID library patch?
2 msgmaybe configure.ac problem ?
1 msg[PATCH] Fix breakage
2 msgr125698 breaks bootstrap on trunk for i686-pc-l...
2 msgDiego Novillo appointed middle-end maintainer a...
2 msgIan Taylor appoined non-algorithmic GWP
1 msgBootstrap failure on trunk
4 msgMerge PTR_PLUS branch?
1 msggcc-4.2-20070613 is now available
2 msgBacktrace() called inside a signal handler trap...
2 msgGenerating a phi node
2 msgBlackfin eh broken with dataflow merge
Subject:Re: [patch,committed] Make Fortran maintainers 'Non-Autopoiesis Maintainers'
Group:Gcc
From:Brooks Moses
Date:15 Jun 2007


(Because this concerns policy rather than code, I've cc'ed it to the
main gcc list rather than the patches list.)

FX Coudert wrote:
> I noticed in MAINTAINERS that there is a new category of "Non-
> Autopoiesis Maintainers" (I certainly missed the original
> announcement), for maintainers who cannot approve their own patches
> (except trivial ones). There is a FIXME in the file that says that
> Fortran maintainers should be added to this category, and it is
> indeed true, since we decided to work under this kind of rule (which,
> I think, is a very positive thing). So, I moved us all in that
> category, except Paul Brook who is one of the original authors for
> the front-end (unfortunately, Steven B. left GCC development recently).

There _was_ no official announcement, save this note under a subject
heading of "[PATCH]: Minor cleanups after the dataflow merge":

http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00723.html

I'm not entirely sure that I agree with formalizing this for the Fortran
maintainers in bulk, at least without discussion. My understanding (and
it's entirely possible that I've missed something) was that this wasn't
so much a formal rule as a general custom -- and, being a custom rather
than a formal rule, unobjectionable to break when appropriate.

I have no objection to this as a custom for GFortran, certainly -- I
think it's a very good idea, and as a custom I very much support it.
However, there have historically been reasonable exceptions to it. In
particular, I've committed several documentation patches without review,
and I have seen a few small patches submitted by maintainers for
comments rather than a formal review and then committed when there were
no dissenting comments. My understanding at the time was that these
were entirely acceptable things to do; is this still true, or no?

Mostly what I want is some discussion about what we expect this to mean
as a formal rule, and how strictly we're expecting to interpret it. For
values of "we" meaning both the GFortran maintainers, and the wider GCC
maintainer community.

(I think I'd also like to register a very small polite complaint about
the introduction of a new category of maintainers without any sort of
announcement or discussion on the gcc@ list, at least insofar as I could
find by searching on "autopoiesis" in the archives.)

> Also, I took this opportunity to change the label of the front-end in
> that file from "fortran 95" to "Fortran", to be more consistent with
> our decision to not mention the 95 standard in the compiler
> description and use the capitalized Fortran spelling. I also
> reordered our names into alphabetical order.

This, I entirely agree with; it had been mildly bugging me for a while.

- Brooks



© 2004-2008 readlist.com