This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] sim and common
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: cgd at broadcom dot com
- Cc: Nick Clifton <nickc at redhat dot com>,Andrew Cagney <ac131313 at redhat dot com>,Geoff Keating <geoffk at redhat dot com>, Ben Elliston <bje at redhat dot com>,"Frank Ch. Eigler" <fche at redhat dot com>, gdb at sources dot redhat dot com
- Date: Thu, 07 Mar 2002 18:08:12 -0500
- Subject: Re: [maint] sim and common
- References: <3C85A44B.6090403@cygnus.com> <yov57koq1ck0.fsf@broadcom.com>
> At Wed, 06 Mar 2002 00:08:27 -0500, Andrew Cagney wrote:
>
>> I'm wondering if it would be helpful for sim specific maintainers (at
>> least for sim/common based sims) to have implicit approval/write
>> permission on the sim/common directory.
>
>
> Uh, I was assuming that in general we (sim maintainers) had write
> after approval perms, but that approval was still required.
> (Concerned by your "write permission" comment there. Do tell me if
> i'm wrong. 8-)
Sim directory maintenance was, for a long time, very vague. I'm trying
to clarify things a little so that people that have a motivation to work
in this directory can do so with little or no hinderance. At the same
time trying to ensure that a few basic procedures are followed.
I think part of this is ensuring that people directly affected by the
infrastructure have a fairly free reign over it.
> Personally, I wouldn't mind someone else having responsibility for
> reviewing my 'common' patches.
Even if you have write privs on sim/common you're still free
(encouraged?) to seek advice from others. (Is this change a good idea?
In 20:20 hindsight was that bit a bad move?)
> I'd like to make sure i'm not doing more damage than i intend, and i
> say 'responsibility' because if somebody doesn't consider it their
> responsibility well, then, it probably won't happen.
Just as long as the damage is limited to ``flesh wounds'' :-) Whats the
worst that could happen - something gets broken? Oops! Actually, I
think that the worst that could happen is for the code's development to
stagnate (unless, that is, there is no one that thinks it is useful).
enjoy,
Andrew