Re: Implement -exec-jump

[Eli Zaretskii <eliz at gnu dot org>]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Wed, 8 Apr 2009 11:36:09 +0400
> Cc: gdb-patches@sources.redhat.com
> 
> On Wednesday 08 April 2009 11:20:43 Eli Zaretskii wrote:
> > > From: Vladimir Prus <vladimir@codesourcery.com>
> > > Date: Wed, 8 Apr 2009 11:08:16 +0400
> > > Cc: gdb-patches@sources.redhat.com
> > > 
> > > > It is okay to _post_ a patch for review saying that the documentation
> > > > patch will be _posted_ later, but actually _committing_ the code part
> > > > is something very different.
> > > 
> > > Is this rule documented anywhere?
> > 
> > I don't know, and I didn't know every request needs a documented rule.
> 
> I believe that a development process that is based on a list of documented
> rules or guidelines is in general more smooth, than one that relies on
> ad-hoc requests.

That's fine with me, but I don't think it means that a request outside
written rules should be automatically rejected just because it isn't
documented.  Our process is just barely documented, so building on
that alone would make our work and cooperation much harder than it
needs to be.

A request to commit changes with docs is not different from a request
to have a test case for each new feature.  I think we should do both.

> > I at least thought it was an accepted truism that we as a team don't
> > want undocumented features.
> 
> I though there's "in a published release" somewhere in the above statement.

That's exactly the point: the release of GDB 7.0 is quite close.
Since we don't have any means to track such issues, you are now
effectively asking me to somehow make sure the appropriate
documentation patch is committed before the release, preferably before
the branch.  I don't have enough free resources to do that, so chances
are we will release GDB 7.0 with this feature undocumented.

I'm talking from experience here, it's not just a theory.  You will
see in the logs that around April 2005 I made several massive changes
to the manual, all of them to document commands and features that were
left undocumented because of lax policies regarding documentation.  I
don't want us to be in such a bad situation ever again, and I don't
have any means of preventing that except by asking that code and
documentation always go together.

> > > Do you think having a window of time where *development version*
> > > has an undocumented feature that is primary targeted at *frontend developers*
> > > is worse than not having that feature at all?
> > 
> > Yes, that's what I think.
> 
> I am 100% sure that both the person who filed the issue this patch
> has fixed, and every single frontend developer, will disagree. And that's
> why it would be best to have documented rules -- so that those rules can
> be established once and we would not spend any more time discussing them.

Well, my rules are spelled out above.  If no one objects, I volunteer
to add them to MAINTAINERS.

> (Even if such established rules increase an already-high overhead of GDB
> hacking to the degree where I won't be able to fix such small bugs).

Frankly, I don't understand why: the particular feature you added now
does not need more than a few lines added to the manual.  Even just
mentioning the command with minimal documentation and a FIXME for
later would be good enough at this point.

In addition, I said many times in the past that if Texinfo and other
technicalities are a burden, contributors can post the documentation
in plain text in their own words, and I will convert them to valid
Texinfo and reword as necessary.  If that makes the burden easier, I'm
here to make good on my promises.

A bit of good will is all I need to make this happen.