This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [commit] Add add_setshow_enum_cmd, use in mips


> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]