public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: Keven Boell <keven.boell@linux.intel.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 1/2] fort_dyn_array: add basic fortran dyn array support
Date: Tue, 26 Jan 2016 12:34:00 -0000	[thread overview]
Message-ID: <20160126123412.GI5146@adacore.com> (raw)
In-Reply-To: <86y4bhr5z8.fsf@gmail.com>

> The reviewing efforts shouldn't justify keeping something in GDB, which
> breaks tests at the beginning.  Patches are reviewed in the scope of
> reviewers' knowledge and experience, so nobody knows the effects of
> patches on the complicated software, such as GDB, on some certain env.
> It is reasonable to me that patches still cause regressions after
> several rounds of careful reviews, but it doesn't mean we should take
> them in source tree.

I hesitated before mentioning the review effort spent on this, and
now I see that I shouldn't have. You are right, the review itself
should not justify one way or the other what to do with the patch.

However,...

> They are fails of tests for the new feature, so they aren't
> regressions.  It could be compiler issues, of course.
[...]
> In short, I am not strongly against this patch as it doesn't cause
> critical problem, and I can live up with it.  However, it would be nice
> to revert it.

I cannot understand why you think that way. If this is just an
issue of a new feature whose implementation has bugs, and no evidence
that it is impacting something else, why would you recommend that
we revert the patch? If we were to revert, no one would be able
to use the new feature; but if we keep it, at least a few people will
be able to enjoy the work that has been done so far.  I don't have
a stake in the feature itself, but I disagree on the logic behind
proposing the revert.

That being said, this is *my* reasoning, and I don't want to argue too
much to avoid creating a culture of "once it is in, it is very hard to
revert".  I'd rather we be revert-easy than the opposite. It would
help if others weighed in on this, as I will accept the choice of
the majority.

>   "A feature which is omitted can always be added later, when its design
> and its implications are well understood.  A feature which is included
> before it is fully understood can never be removed later."
> 
>   -- C.A.R. Hoare, The Emperor's Old Clothes, 1980 Turing Award Lecture

Does not apply here, IMO, because the syntac is dictated by the
language, and it's not going to change. The only thing we can do
is fix the bugs we find.

-- 
Joel

  reply	other threads:[~2016-01-26 12:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-01 12:42 [PATCH 0/2] fort_dyn_array: Enable basic Fortran dynamic " Keven Boell
2015-07-01 12:42 ` [PATCH 2/2] fort_dyn_array: add basic test coverage Keven Boell
2015-07-21 18:19   ` Joel Brobecker
2015-08-05 13:41     ` Keven Boell
2015-07-01 12:42 ` [PATCH 1/2] fort_dyn_array: add basic fortran dyn array support Keven Boell
2015-07-21 18:05   ` Joel Brobecker
2015-08-05 13:41     ` Keven Boell
2015-08-05 13:47     ` Keven Boell
2015-08-05 20:23       ` Joel Brobecker
2015-08-06 11:42         ` keven.boell
2015-08-20 12:52           ` Joel Brobecker
2015-10-09 11:37             ` Keven Boell
2015-10-22  9:59               ` Joel Brobecker
2016-01-20 10:19               ` Yao Qi
2016-01-22  7:22                 ` Keven Boell
2016-01-22 12:40                   ` Joel Brobecker
2016-01-22 15:25                     ` Yao Qi
2016-01-26 12:34                       ` Joel Brobecker [this message]
     [not found]             ` <5613D0DC.3040908@linux.intel.com>
2015-10-22  9:59               ` Joel Brobecker
2015-10-28 15:30 ` off-trunk gdb.fortran/dwarf-stride.exp no longer PASSes [Re: [PATCH 0/2] fort_dyn_array: Enable basic Fortran dynamic array support] Jan Kratochvil
2015-10-28 16:19   ` Jan Kratochvil
2015-10-28 18:54     ` Joel Brobecker
2015-10-30 10:39       ` Jan Kratochvil
2015-11-04 21:48         ` Joel Brobecker
2015-11-04 22:08           ` Jan Kratochvil
2015-11-05  7:31             ` Keven Boell
2015-11-05  8:22               ` Jan Kratochvil
2015-11-05 16:05                 ` Keven Boell
2016-02-08 13:47 [PATCH 1/2] fort_dyn_array: add basic fortran dyn array support Walfred Tedeschi
2016-02-09 11:36 ` Joel Brobecker
2016-02-09 15:14   ` Walfred Tedeschi

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=20160126123412.GI5146@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keven.boell@linux.intel.com \
    --cc=qiyaoltc@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).