Re: MAINTAINERS policy question

[mike stump <mrs at windriver dot com>]

> From: Andreas Jaeger <aj@suse.de>
> Date: Sun, 16 Sep 2001 20:14:57 +0200

> --- cvswrite.html.~1~	Thu Jul 26 16:10:30 2001
> +++ cvswrite.html	Sun Sep 16 20:13:24 2001
> @@ -98,7 +98,13 @@
>    primary responsibility for ports, front ends, or significant hunks
>    of code in the compiler.  These folks are allowed to make changes in
>    code they maintain without going through any kind of approval
> -  process.</dd>
> +  process.
> +
> +  <p>
> +  Maintainers of a port maintain the files in config/&lt;port&gt;/,
> +  the configure fragments for the port, documentation for the port and
> +  test cases for features or bugs specific to this port.  Port
> +  maintainers do not have approval writes in other files.  </dd>

I mostly agree as well.

The part about testcases and bugs specific to a port is a little to
general.  Basically, a port maintainer has privs for all those bytes
that _only_ affect ports under his control, if they are normally done
in such a manner.

This would mean that a bug fix to libgcc2.c in:

#if defined (sony_news) && defined (SYSTYPE_BSD)

#include <stdio.h>
#include <sys/types.h>
#include <sys/param.h>
#include <syscall.h>
#include <machine/sysnews.h>

/* cacheflush function for NEWS-OS 4.2.
   This function is called from trampoline-initialize code
   defined in config/mips/mips.h.  */

void
cacheflush (char *beg, int size, int flag)
{
  if (syscall (SYS_sysnews, NEWS_CACHEFLUSH, beg, size, FLUSH_BCACHE))
    {
      perror ("cache_flush");
      fflush (stderr);
      abort ();
    }
}

#endif /* sony_news */

would be OK by the sony_news/mips maintainer.  My wording also makes
it clear that an FreeBSD maintainer can change the FreeBSD make file
fragments, but not the Linux parts of the x86 files.  Adding a

#ifdef __mips
[ hack around ]
#endif

into MI code, would not be acceptable, unless signed off by a
maintainer of the MI code.

Testcases are potentially hard to decide.  A testcase _should_ be done
in a fairly MI way.  A port maintainer can miss ways in which a
testcase is machine dependent.  Having someone else review the
testcase is reasonably a good idea.  A port maintainer that can
generate a MI testcase I think should be allowed to just check it in
directly.

I am in favor of having things loosely defined, and leaving a little
wiggle room.  Those people that are new/inexperienced should caution
to the conservative side, those that are very experienced should be
granted just a little bit more leeway in what parts they change.