Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: Jim Blandy <jimb@zwingli.cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: Rewriting the type system
Date: Tue, 12 Jun 2001 01:44:00 -0000	[thread overview]
Message-ID: <Pine.SUN.3.91.1010612114355.1700J-100000@is> (raw)
In-Reply-To: <87d78aluw6.fsf@cgsoftware.com>

On 11 Jun 2001, Daniel Berlin wrote:

> Even the very simple patch to add the misc obstack to the objfiles,
> and stop putting things in the psymbol obstack that don't belong, from
> May 29th, hasn't been reviewed yet.
> Hell, the simple bcache change i submitted last year (updating the
> starting constant, fix the indenting) still hasn't
> been reviewed.
> 
> Jim, GDB development is moving a lot slower than it should.

My experience is very different.  Every change that I suggested until
now, for the past 2 years or so that I'm involved with GDB
maintenance, was usually reviewed within 1-2 weeks of my posting it
as an RFA.  A few times I needed to post a reminder (I usually do that
after more than a week's passed without any replies).  A couple of
times, I needed more than one reminder, but that's an exception rather
than the rule, in my experience.

In most cases, I had my patches reviewed and approved in 2-3 weeks,
sometimes a month.  In one exceptional case, it took 3 or 4 months,
but that was my first large submission, and I failed to ping the
relevant maintainer more than once.

So GDB development is not slow, in my opinion.  More importantly, I'm
always able to get my patches accepted by using the normal channels,
such as pinging people from time to time.

In other words, the development procedures work.

> If someone told me, after just rewriting the typesystem, that i
> needed to redo it from scratch, i'd probably just start making my
> own GDB releases instead (in effect, forking GDB).

As I already wrote elsewhere, if you care about GDB, please stop
talking about a fork, because even talking about it can do a
tremendous damage to the nice cooperative development atmosphere we
have in GDB.  I've been and am involved in quite a few other free
software packages, and I'm telling you that GDB is one of the nicest,
most cooperative environments I had ever experienced.  Please, let's
cherish that!

While there's always place for improvement, let's suggest such
improvements in a constructive way, and let's assume that everybody in
this fine forum has the same goal: making GDB better.  Offending
people by talking about a fork is not a good way, to say the least, of
asking them to be more responsive to your submissions.  It _is_,
however, an efficient way of making cooperation harder.

(I'm sorry about lecturing, but I cannot in good faith look the other
way when people talk about forking.)


  parent reply	other threads:[~2001-06-12  1:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-07 23:22 obvious set_cu_language patch Per Bothner
2001-06-07 23:50 ` Daniel Berlin
2001-06-08 11:01   ` Per Bothner
2001-06-08 14:04     ` Stan Shebs
2001-06-08 14:34       ` Daniel Berlin
2001-06-08 13:04 ` Andrew Cagney
     [not found]   ` <m2pucevgf6.fsf@kelso.bothner.com>
2001-06-08 13:51     ` Daniel Berlin
     [not found]       ` <8766e6eke4.fsf@creche.redhat.com>
2001-06-08 14:23         ` Per Bothner
     [not found]       ` <npelsq28sh.fsf_-_@zwingli.cygnus.com>
2001-06-11 11:43         ` Rewriting the type system Daniel Berlin
2001-06-11 16:58           ` Stan Shebs
2001-06-12  1:44           ` Eli Zaretskii [this message]
2001-06-12  9:12             ` Daniel Berlin
2001-06-12 10:01               ` Eli Zaretskii
2001-06-12 10:16           ` Jim Blandy
2001-06-12 10:44             ` Daniel Berlin
2001-06-12 14:02               ` Stan Shebs
2001-06-13  1:45                 ` Eli Zaretskii
2001-06-12 11:08             ` Daniel Berlin
2001-06-12 14:03           ` Andrew Cagney
2001-06-12 21:37             ` Daniel Berlin
2001-06-25 14:13 ` obvious set_cu_language patch Elena Zannoni

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=Pine.SUN.3.91.1010612114355.1700J-100000@is \
    --to=eliz@is.elta.co.il \
    --cc=dan@cgsoftware.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jimb@zwingli.cygnus.com \
    /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