From: mike stump <mrs@windriver.com>
To: aj@suse.de, mark@codesourcery.com
Cc: bernds@redhat.com, gcc@gcc.gnu.org
Subject: Re: MAINTAINERS policy question
Date: Mon, 17 Sep 2001 17:40:00 -0000 [thread overview]
Message-ID: <200109180038.RAA27823@kankakee.wrs.com> (raw)
> 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/<port>/,
> + 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.
next reply other threads:[~2001-09-17 17:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-17 17:40 mike stump [this message]
2001-09-18 16:30 ` Marc Espie
-- strict thread matches above, loose matches on Subject: below --
2001-09-17 9:44 Ulrich Weigand
2001-09-16 11:46 Richard Kenner
2001-09-16 12:24 ` Andreas Jaeger
2001-09-16 8:38 Richard Kenner
2001-09-16 6:39 Richard Kenner
2001-09-16 8:35 ` Daniel Berlin
2001-09-16 6:04 Ulrich Weigand
2001-09-16 18:19 ` DJ Delorie
2001-09-16 2:52 Bernd Schmidt
2001-09-16 3:12 ` Andreas Jaeger
2001-09-16 3:38 ` Graham Stott
2001-09-16 10:59 ` Mark Mitchell
2001-09-16 11:16 ` Andreas Jaeger
2001-09-16 11:17 ` Mark Mitchell
2001-09-16 11:22 ` Toon Moene
2001-09-16 11:23 ` Gerald Pfeifer
2001-09-16 14:14 ` David Edelsohn
2001-09-17 8:32 ` Phil Edwards
2001-09-16 4:06 ` Joseph S. Myers
2001-09-16 15:04 ` Joe Buck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200109180038.RAA27823@kankakee.wrs.com \
--to=mrs@windriver.com \
--cc=aj@suse.de \
--cc=bernds@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=mark@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).