This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Reviewers Was: Re: Fortran/PR19303 PATCH: Runtime selection ofrecord markers for unformatted sequential io
- From: Gerald Pfeifer <gerald at pfeifer dot com>
- To: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Cc: fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Thu, 24 Feb 2005 21:39:39 +0100 (CET)
- Subject: Re: Reviewers Was: Re: Fortran/PR19303 PATCH: Runtime selection ofrecord markers for unformatted sequential io
- References: <14015017.1109047888175.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net><3677420.1109197619353.JavaMail.root@dtm1eusosrv72.dtm.ops.eu.uu.net><421E237A.2020809@moene.indiv.nluug.nl>
On Thu, 24 Feb 2005, Toon Moene wrote:
> Here's what I came up with (attached).
Wearing my wwwdocs hat, I've got some comments, but not many. ;-)
Some of the lines are a bit long, it would be good to avoid lines longer
than, say 75 or so, characters.
--- index.html Thu Feb 24 19:51:06 2005
+ <li>All normal requirements for patch submission (testing, changelog entries,
+ etc) still apply, and reviewers should ensure that these have been met before
+ approving changes.</li>
I believe a link from "normal requirements" to contribute.html would be a
good idea.
+ <li>Approval should be necessary for patches which don't fall under the
+ obvious rule, so with this list put in place everybody (except maintainers)
+ should <b>still</b> seek approval for his/her patches.</li>
<em>still</em> or <strong>still</strong>
+ <li>Patches should only be reviewed by people who know the affected parts of
+ the compiler. I.e. the reviewer has to be sure he/she knows stuff well enough to
+ make a good judgement.</li>
Listing this a special requirement here might be considered as an
indication that this is generally not required?
+ <li>We are all reasonable people, and nobody is working under employer pressure
+ or needs an ego-boost badly, so in general we assume that noone
+ deliberately does anything stupid :-)</li>
Hmm, do we really need that? There is some fun factor attached to that,
but I generally try to avoid this kind of statements and also try to
keep docs as short as possible.
Gerald