This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
[MAINT/RFC] Start devolving maintenance responsibility
- To: GDB Discussion <gdb at sourceware dot cygnus dot com>
- Subject: [MAINT/RFC] Start devolving maintenance responsibility
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 01 Mar 2000 13:34:08 +1100
- CC: GDB Patches <gdb-patches at sourceware dot cygnus dot com>
- Organization: Cygnus Solutions
Hello,
GDB's been on sourceware for a whole month so its now probably time time
to start devolving more responsibility :-)
With that in mind, I'm proposing the attatched change. It hopefully
achieves the following:
o allows the maintainers
within a domain to self
organize
o clearly identify who
is ultimately responsible
for a maintenace domain
(where the buck stops :-)
o provides a suggested fraomewor
within which domain maintainers
can work.
Comments? I'm going to leave this tabled for at lest a week as I know
of at least two maintainers that are off line right now.
Andrew
Wed Mar 1 12:29:35 2000 Andrew Cagney <cagney@b1.cygnus.com>
* MAINTAINERS: Devolve responsibility for domain maintenance to
the domain maintainers.
? diffs
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.88
diff -p -r1.88 ChangeLog
*** ChangeLog 2000/03/01 00:45:18 1.88
--- ChangeLog 2000/03/01 02:31:28
***************
*** 1,3 ****
--- 1,8 ----
+ Wed Mar 1 12:29:35 2000 Andrew Cagney <cagney@b1.cygnus.com>
+
+ * MAINTAINERS: Devolve responsibility for domain maintenance to
+ the domain maintainers.
+
2000-03-01 Mark Kettenis <kettenis@gnu.org>
* MAINTAINERS: Correct my own mail address.
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.16
diff -p -r1.16 MAINTAINERS
*** MAINTAINERS 2000/03/01 00:45:18 1.16
--- MAINTAINERS 2000/03/01 02:31:31
*************** Stan Shebs shebs@cygnus.com
*** 8,24 ****
Various Maintainers
! Note individuals who maintain parts of the debugger need approval to
! check in changes outside of the immediate domain that they maintain.
! If there is no maintainer for a given domain then the problem falls to
! the head maintainer.
! If there are several maintainers for a given domain then the problem
! falls to the first maintainer. The second and third maintainers are
! firstly known to have expertise in the given domain and secondly are
! available to step in if the first maintainer is to be absent for any
! reason.
Target/Architecture:
--- 8,29 ----
Various Maintainers
! Individuals who make changes to the debugger need approval from all
! relevant domain maintainers before those changed can be checked in.
! If there is no maintainer for a given maintenance domain then approval
! is the responsibility of the head maintainer.
! If there are several maintainers for a given maintenance domain then
! approval is the responsibility of the first maintainer. How exactly
! that responsibility is administered is also the responsibility of the
! first maintainer.
!
! Typically, when there are several maintainers, the first maintainer
! will devolve all responsibility for that domain to that domains
! maintainers. Individuals making changes within their domain would
! have major changes approved through consensus (with their peers) while
! minor tweaks would not need approval.
Target/Architecture: