Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,
	cagney@gnu.org, gdb-patches@sources.redhat.com
Subject: Re: [commit] Add add_setshow_enum_cmd, use in mips
Date: Wed, 10 Nov 2004 23:41:00 -0000	[thread overview]
Message-ID: <20041110234143.GA32661@nevyn.them.org> (raw)
In-Reply-To: <01c4c77c$Blat.v2.2.2$a7e52160@zahav.net.il>

On Thu, Nov 11, 2004 at 01:25:05AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 10 Nov 2004 22:42:14 +0100 (CET)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > CC: cagney@gnu.org, drow@false.org, gdb-patches@sources.redhat.com
> > 
> > Sorry, but I have to disagree here.  For the (unfortunately) limited
> > number of people that contribute several patches in a week this is a
> > significant problem.  When I'm working on a particular area I often
> > find myself making multiple changes to the same file.  If I have to
> > post a patch and wait a week before I can check it in, I have two
> > options:
> > 
> > 1. Juggle with the patches for a week, risking an accidental commit of
> >    stuff belonging to a different patch to the same file, or dropping
> >    a patch completely in the process.
> > 
> > 2. Postpone further work on that part of GDB until the week is over
> >    and the patch has been committed.
> > 
> > Neither option is good for GDB.

I completely agree with Mark.

> That might be tough, but we all do precisely that when the file in
> question is not in our maintainership area.

You've said that quite a few times now :-)  But this isn't a documented
policy, and it doesn't seem to be a widely followed one, either.  This
seems to be the heart of our disagreement.

> Yes, it slows down the development a bit, but I don't think the patch
> rate is our most important goal.  The rate is important, but code
> quality and clean design are IMHO more important.

We can't improve the code quality and design, which have suffered over
time, if we can't make progress on patches.  Indeed, the longer it
takes for every single change to go in, the less incentive there is to
clean anything up!  I'm sure losing incentive to fix things.

-- 
Daniel Jacobowitz


  reply	other threads:[~2004-11-10 23:41 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 [this message]
2004-11-11  0:00                                 ` Eli Zaretskii
2004-11-11  5:37                                   ` Daniel Jacobowitz
2004-11-11  5:59                                     ` Joel Brobecker

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=20041110234143.GA32661@nevyn.them.org \
    --to=drow@false.org \
    --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