* Re: [patch] Deprecate XM_FILE and TM_FILE
[not found] ` <20040913213015.GC5843@gnat.com>
@ 2004-09-15 12:50 ` Eli Zaretskii
0 siblings, 0 replies; only message in thread
From: Eli Zaretskii @ 2004-09-15 12:50 UTC (permalink / raw)
To: Joel Brobecker; +Cc: cagney, gdb
[I've moved this to gdb@, as gdb-patches@ seems an improper place to
discuss such issues.]
> Date: Mon, 13 Sep 2004 14:30:15 -0700
> From: Joel Brobecker <brobecker@gnat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, kettenis@gnu.org,
> gdb-patches@sources.redhat.com
>
> 1. When can some code be declared deprecated?
>
> IMO, some code should be declared deprecated when it has been
> recognized that it should no longer be used in new changes.
> It means that some code can be identified as deprecated before
> a replacement has been implemented.
"Identified as deprecated" and "declared deprecated" need not happen
at the same time. That time might (and IMHO should) be used to
implement the replacement.
> There is a judgement call to make, obviously, as we don't want to
> deprecate a central piece of GDB that makes it impossible for
> somebody to submit a new port for instance without doing man-years
> of work required to implement an alternate to the deprecated
> feature.
I note that you didn't suggest any way out of this contradiction. I
did suggest such a way: implement and commit the alternate mechanism
before or together with the patch that marks the old code deprecated.
> 2. How to identify deprecated code?
>
> Deprecated code should be explicitly marked as such directly
> in the code, to avoid any accidental future usage, by prepending
> "depreated_" to the entity names.
This doesn't ensure that accidental future use is avoided, because not
all contributors have the latest CVS before their eyes when they work
on their contribution.
A requirement that everything important for the contributor to get
his/her code right the first time be in the code is IMHO ridiculous:
it will, for example, cause us to spill a large part of gdbint.texinfo
into the sources, as well as the contents of MAINTAINERS and PROBLEMS.
The correct (IMHO) way out of this predicament is to request that
contributors read all the relevant pieces of code and documentation
(if they don't know, they can ask where to look). Of course, this
doesn't eliminate a possibility that they will overlook, but I'm not
aware of any project that avoided that with a 100% insurance; I don't
see why this should be such a great deal here.
More generally, AFAIR the "depreated_" stunt was invented mainly as an
aid to the maintainer(s): to make their job easier when they want to
know what stuff is candidate for deletion. It is a bit funny to see
this convenience trick sudenly being inflated with so much ideology.
> You should decide how the discussion will be held (privately or on
> gdb-patches?), and whether it should include the steering committee
> or not.
IMHO, the steering committee is just a slogan: they never contributed
anything helpful in any important discussion we've had lately, or
ever. So I think gdb@ is a good place to discuss this.
In any case, one thing that I think should never happen is that a
global maintainer posts a patch a which deprecates a feature used by a
maintained port without first asking for an _explicit_ approval of
that port's maintainer for such a move[1]. That is not only good
management practice (that is AFAIK codified in our procedures), it is
also what simple decency to one's colleagues suggests. If we fail to
agree to that, then we are not a team, but simply a bunch of unrelated
people, each one pursuing his/her own agenda.
------------------
[1] One exception is when the area/port maintainer is unresponsive to
the degree that it is impractical to wait for his/her approval or
disapproval.
^ permalink raw reply [flat|nested] only message in thread