From: Joel Brobecker <brobecker@gnat.com>
To: Eli Zaretskii <eliz@gnu.org>,
mark.kettenis@xs4all.nl, cagney@gnu.org,
gdb-patches@sources.redhat.com
Subject: Re: [commit] Add add_setshow_enum_cmd, use in mips
Date: Thu, 11 Nov 2004 05:59:00 -0000 [thread overview]
Message-ID: <20041111055903.GX649@gnat.com> (raw)
In-Reply-To: <20041111053707.GA9394@nevyn.them.org>
> > Then let's abandon the patch reviewing procedure completely and just
> > commit whatever each one of us global maintainers finds appropriate.
> > There are projects that actually work that way (Emacs, for example).
> > I have no problem with that, as long as it is consistent and
> > documented.
FWIW, I am in favor of such an approach. At AdaCore, this is pretty much
how we work, and we have found that it works very well. The review
happens after commit. Some times we screw up, and we have to either
fix the screwup or revert, but most of the time the change is correct.
All in all, we save a lot of time this way. The part that we realize
is that with such a model, being questioned on a patch and maybe having
to revert it is considered normal. So we don't take any offense at
such comments, and don't consider this as a judgement of our abilities.
We also rely on the engineers' judgement to call for a review before
commit when this make sense. For instance, when a change is trickier
than usual, or he's unsure of his fix, or when something needs a design
that could benefit from peers' feedback, or when something impacts
a lot of code, etc.
But all in all, it is largely more effective for us to commit and
then review.
> I've suggested something along those lines (not "abandoning patch
> reviewing", but giving more authority to the global maintainers)
> several times in the past, and met with mixed responses. I hope to
> eventually discuss this question with the GDB Steering Committee, and
> get the result documented, one way or another.
--
Joel
prev parent reply other threads:[~2004-11-11 5:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-30 17:11 Andrew Cagney
2004-10-30 23:24 ` Eli Zaretskii
2004-10-31 23:01 ` Andrew Cagney
2004-11-01 4:47 ` Eli Zaretskii
2004-11-01 5:12 ` Daniel Jacobowitz
2004-11-01 21:15 ` Eli Zaretskii
2004-11-01 22:37 ` Daniel Jacobowitz
2004-11-02 4:51 ` Eli Zaretskii
2004-11-09 1:15 ` Daniel Jacobowitz
2004-11-09 5:00 ` Eli Zaretskii
2004-11-09 15:29 ` Andrew Cagney
2004-11-09 18:42 ` Daniel Jacobowitz
2004-11-10 4:33 ` Eli Zaretskii
2004-11-10 20:55 ` Eli Zaretskii
2004-11-10 21:42 ` Mark Kettenis
2004-11-10 23:31 ` Eli Zaretskii
2004-11-10 23:41 ` Daniel Jacobowitz
2004-11-11 0:00 ` Eli Zaretskii
2004-11-11 5:37 ` Daniel Jacobowitz
2004-11-11 5:59 ` Joel Brobecker [this message]
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=20041111055903.GX649@gnat.com \
--to=brobecker@gnat.com \
--cc=cagney@gnu.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=mark.kettenis@xs4all.nl \
/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