This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Discussion: Formalizing the deprecation process in GDB


> 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.

> 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.

> > If you do want to try to convince me, you (or someone else who thinks
> > like you) will have to do better than that.
> 
> Now that cuts both ways, you've not convinced anyone either :-(

I didn't start this thread.  If we have nothing new to say to each
other, perhaps we should just stop, since no one else seems to be
interested.

> > I'm not sure what is it that you are saying here.  Should we abandon
> > gdbint.texinfo and instead rely on the code to explain itself, because
> > ``we are programmers and thus code is the only thing we read''?  Maybe
> > I should stop trying so hard to review each documentation patch in a
> > matter of days, because the code already says all there is to tell?
> 
> [Sarcasm] Obviously, that's why I'm spending part of my time on 
> internals documentation.

And I know that, so I'm stunned to read words you've written that
discourage documentation efforts.

> 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.

> 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.

No slur was intended, of course; sorry if it sounded like that.

> 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.

> - 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.

Yes, that _is_ harder than leaving things unmodified (i.e. broken),
but that is the price we pay for the fun of being maintainers.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]