This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] fort_dyn_array: add basic fortran dyn array support
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: Keven Boell <keven dot boell at linux dot intel dot com>, gdb-patches at sourceware dot org
- Date: Tue, 26 Jan 2016 16:34:12 +0400
- Subject: Re: [PATCH 1/2] fort_dyn_array: add basic fortran dyn array support
- Authentication-results: sourceware.org; auth=none
- References: <20150721180502 dot GN7406 at adacore dot com> <55C213C7 dot 7070202 at linux dot intel dot com> <20150805202301 dot GB14992 at adacore dot com> <51130 dot 172 dot 28 dot 205 dot 135 dot 1438861308 dot squirrel at linux dot intel dot com> <20150820125159 dot GD4571 at adacore dot com> <5617A6FB dot 4050407 at linux dot intel dot com> <86oacgsgdx dot fsf at gmail dot com> <56A1D8CD dot 3040905 at linux dot intel dot com> <20160122124050 dot GG5146 at adacore dot com> <86y4bhr5z8 dot fsf at gmail dot 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