* GDB's roles
@ 2003-02-21 18:43 Andrew Cagney
2003-02-21 18:51 ` Daniel Jacobowitz
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-02-21 18:43 UTC (permalink / raw)
To: gdb
Ignoring the upper levels, I think the people listed in the gdb
MAINTAINERS file find themselves filling one or more of the following roles:
Elders:
These are the keepers of the `GDB wisdom'. They are largely uninvolved
in day to day GDB development - very hands off - very much don't given
opinions except where to point out problems and flaws.
Adminstrator:
They do the day to day stuff: bug report unreviewed patches, ping
maintainers that are asleep at the wheel, try to keep the political
(RMS, et.al.) separate from the technical (this groups focus), web
pages, ...
Architect:
Ensure that GDB is `heading in the right direction'. The actual
direction is determined by the group but this person gets to watch for
things going off the rails. Also, very occasionally, make architectural
judgment calls.
The architect is woried about key interfaces such as the architecture
and target vectors.
Core Maintainers:
These are the people on which everyone else depends. They put
themselves to the grindstone ensuring that the GDB wheel keeps turning.
These are the people that do the hard work of reviewing / approving
patches. These people need to be relatively reliable. These people
need to be willing to do the dirty work (such as restructuring) that
can't reasonably be expected of a contributor.
While a core maintainer might also be responsible for certain specific
areas (symtab, threads, remote), they won't cherry pick the patch list
and definitly won't fall asleep at the wheel.
Specific Maintainers:
These are responsible for specific areas. Native, target, host and
language maintainers come to mind. Their responsabilities are pretty
clear, while needing to be responsive, they are not on the critical path
like core maintainers. The thing I really like about the target
maintainers is how they, every so often, pop up to do some maintenance
(eliminate something deprecated), and then pop back down again.
Developers/Contributors:
These are the people that have `fun'. They have the luxury of poping
up, contributing a new feature, and then simply disappearing again
(typically though, a contributor ends up being the maintainer). New
development, of course, needs peer review (by a maintainer) as, in the
long run, it will be the [core] maintainers that have to support that code.
Using the above as a reference (the last thing this list needs is a long
irrelevant discussion about the semantics of each of the above :-)) it
might be helpful for global maintainers to look at this so that they can
see how their activities contribute to GDB.
Me? Architect/Adminstrator + core. While I'm a maintainer for a few
specific area's (remote and mips) that is very very low down, same for
development.
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GDB's roles
2003-02-21 18:43 GDB's roles Andrew Cagney
@ 2003-02-21 18:51 ` Daniel Jacobowitz
2003-02-21 20:21 ` Andrew Cagney
2003-02-21 20:44 ` Andrew Cagney
0 siblings, 2 replies; 4+ messages in thread
From: Daniel Jacobowitz @ 2003-02-21 18:51 UTC (permalink / raw)
To: gdb
On Fri, Feb 21, 2003 at 01:48:06PM -0500, Andrew Cagney wrote:
> Core Maintainers:
>
> These are the people on which everyone else depends. They put
> themselves to the grindstone ensuring that the GDB wheel keeps turning.
> These are the people that do the hard work of reviewing / approving
> patches. These people need to be relatively reliable. These people
> need to be willing to do the dirty work (such as restructuring) that
> can't reasonably be expected of a contributor.
>
> While a core maintainer might also be responsible for certain specific
> areas (symtab, threads, remote), they won't cherry pick the patch list
> and definitly won't fall asleep at the wheel.
>
>
> Specific Maintainers:
>
> These are responsible for specific areas. Native, target, host and
> language maintainers come to mind. Their responsabilities are pretty
> clear, while needing to be responsive, they are not on the critical path
> like core maintainers. The thing I really like about the target
> maintainers is how they, every so often, pop up to do some maintenance
> (eliminate something deprecated), and then pop back down again.
One of my concerns from my previous thread about this, which seems to
have died, is that the above doesn't completely describe current
structure. The set of core maintainers breaks down into specific
maintainers for core components.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GDB's roles
2003-02-21 18:51 ` Daniel Jacobowitz
@ 2003-02-21 20:21 ` Andrew Cagney
2003-02-21 20:44 ` Andrew Cagney
1 sibling, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 2003-02-21 20:21 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
> On Fri, Feb 21, 2003 at 01:48:06PM -0500, Andrew Cagney wrote:
>
>> Core Maintainers:
>>
>> These are the people on which everyone else depends. They put
>> themselves to the grindstone ensuring that the GDB wheel keeps turning.
>> These are the people that do the hard work of reviewing / approving
>> patches. These people need to be relatively reliable. These people
>> need to be willing to do the dirty work (such as restructuring) that
>> can't reasonably be expected of a contributor.
>>
>> While a core maintainer might also be responsible for certain specific
>> areas (symtab, threads, remote), they won't cherry pick the patch list
>> and definitly won't fall asleep at the wheel.
>>
>>
>> Specific Maintainers:
>>
>> These are responsible for specific areas. Native, target, host and
>> language maintainers come to mind. Their responsabilities are pretty
>> clear, while needing to be responsive, they are not on the critical path
>> like core maintainers. The thing I really like about the target
>> maintainers is how they, every so often, pop up to do some maintenance
>> (eliminate something deprecated), and then pop back down again.
> [...] The set of core maintainers breaks down into specific
> maintainers for core components.
The paragraph:
>> While a core maintainer might also be responsible for certain specific
>> areas (symtab, threads, remote), they won't cherry pick the patch list
>> and definitly won't fall asleep at the wheel.
is trying to express this.
core different to maintainers of sub-systems such as the target, native,
language or host. The critical nature of a core maintainer isn't there
though. Typically maintainers of nat, tdep, et.al. code are in a `if it
ain't broke / deprecated, don't fix it' situtation. While fixes/patches
should make it into the next release, they are not so much on the
critical path.
Contrast that to my current core activity of rewriting frames. I'm on
the hook for everything.
Anyway, the main thing is that my post is a `white paper', a discussion
`puff piece'.
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GDB's roles
2003-02-21 18:51 ` Daniel Jacobowitz
2003-02-21 20:21 ` Andrew Cagney
@ 2003-02-21 20:44 ` Andrew Cagney
1 sibling, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 2003-02-21 20:44 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
>
> One of my concerns from my previous thread about this, which seems to
> have died, ...
`shit happens'.
If you check your mailbox you'll notice an e-mail I sent in november to
the global maintainers that identified a number of problem areas (from
memory, I delayed sending it until you'd been made a global maintainer).
You'll note that Java was top of that list and I've since managed to
resolve it - Java patches have just started to flow again. Your
discussion has helped clarify a few things and re-prioritize accordingly.
As the `adminstrator', I get to follow through all of this.
Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-02-21 20:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-21 18:43 GDB's roles Andrew Cagney
2003-02-21 18:51 ` Daniel Jacobowitz
2003-02-21 20:21 ` Andrew Cagney
2003-02-21 20:44 ` Andrew Cagney
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).