Re: Discussion: Formalizing the deprecation process in GDB

[Mark Kettenis <kettenis@gnu.org>]

   Date: Mon, 11 Oct 2004 22:42:57 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Mon, 11 Oct 2004 02:10:02 -0400
   > From: Andrew Cagney <cagney@gnu.org>
   > Cc: gdb@sources.redhat.com
   > 
   > I can only guess or suspect.  E-mail being a primative medium doesn't 
   > let us read between the lines and identify when there's an underlying 
   > issue.

   I don't know why you insist on trying to read between the lines and
   look for hidden issues.  I try very hard to make the issues that
   bother me as explicit as I possibly can.

I can't speak for Andrew, but what personally surprised me is why all
of I sudden you seem to be opposed to deprecating things.

   > The "users" I interact with appreciate the more timely releases that 
   > give them faster acces to fixes, so I don't know what is "harsh" here. 
   > Can you explain?

   When we retire some code or feature or platform, we hurt users of that
   code or feature or platform.

Only to the extent that we rob them of any further improvements for
their platform.  In my experience though we're not actually
deliberately retiring features or platforms.  Yes, we've been
obsoleting stuff, but in almost all cases this has actually been a
service to our users, since we save them the disappointment of
discovering that GDB doesn't work at all on their platform after they
built it.  So I'm afraid you haven't actually answered Andrew's
question :-(.

   > The internals documentation should contain the process, or the overview. 

   I think it can contain whatever we find useful to have there.  There's
   nothing wrong with the idea that the internals docs will serve us a
   little, not just people outside the GDB development team.  The
   documentation of the GDB release and branching processes are very good
   examples.

Yes, but if there's an obvious place for documentation in the code
it's probably better to but it there.  For example, SPARC-specific
stuff is better documented in sparc-tdep.c, core file related stuff
probably belongs in corelow.c.

   > Looking in 4.18 (, I'd been adding comments and code marking various 
   > pieces of gdb as "deprecated.
   > 
   > By 5.0 (2000-05) I was explicitly deprecating things.

   My involvement with GDB goes back to 4.16 (although you probably won't
   find the traces in the logs).

   Perhaps my memory betrays me, but the massive use of deprecated_ is
   something that didn't start until 5.x.  You seem to confirm that,
   although not in so many words.

Yup.  Using deprecated_ is "explicitly deprecating" in my book.  I
understand your revulsion against the use of deprecated_ in the source
code, and I did oppose to it in the past.  However, it really has the
benefits Andrew describes.  I think that sometimes he goes to far.
For eah deprecation there should be an alternative that's somewhat
easy to implement.  The DEPRECATED_TM_FILE is bad in this sense, since
it is impossible to add a platform with SVR4-style shared libraries
without using it, unless you refactor the shared library code.  On the
other hand, that's about the only thing that needs it, and
DEPRECATED_TM_FILE serves the purpose of keeping people from using it
liberally.  I don't thing we should only deprecate things if all
that's needed to undeprecate is a simple substitution.

If maintainers do their job right they'll undeprecate the code they're
maintaining as soon as possible.  I think I've proven that this can be
done.  But I think the deprecator has at least an equal burden to
undeprecate if he's able to do so.

   > Are you suggesting that I should be required to fix the fringes?

   Not necessarily you.

   In every other GNU project that I was involved with, the person who
   wants to make a change is required to make sure nothing is broken by
   the change without an overall agreement that it is okay to break it.
   Breaking things just because no one is willing to make an effort to
   fix them is something I find to be very wrong.

I think it is unavoidable if we want to keep GDB maintainable.  In the
end if no-one undeprecates a particular feauture or platform, we can
conclude that no-one is actively maintaining that part of code.

   > - we've consistently demonstrated that untested changes don't work.

   Then the person who makes the changes needs to test them, or ask
   someone else to do that for them, if access to some specific platform
   is an issue.

There are quite a few platforms for which no active GDB developer has
access to a usable system.  Enforcing this would actually slow down
development to a crawl.  We really have to find a balance here.

Mark