Re: Implement -exec-jump

[Thiago Jung Bauermann <bauerman@br.ibm.com>]

El mié, 08-04-2009 a las 12:26 +0300, Eli Zaretskii escribió:
> > From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= <andre.poenitz@nokia.com>
> > Date: Wed, 8 Apr 2009 10:16:41 +0100
> > 
> > On Wednesday 08 April 2009 09:20:43 Eli Zaretskii wrote:
> > > > From: Vladimir Prus <vladimir@codesourcery.com>
> > > [...]
> > > > 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 disagree.
> 
> Well, you are not responsible for the GDB documentation; I am.
> 
> If we are going to allow committing undocumented code, I would ask to
> install some procedures to make sure it gets documented eventually.

I agree with Eli here. If we don't have a mechanism of ensuring that
documentation will get written before a release, we should enforce that
features always be committed with documentation.

OTOH, if we agree that it's acceptable to have a time window where CVS
HEAD has undocumented features (as long official releases are always
documented), then I think we should discuss those mechanisms, since as
Vladimir and André say, it does help GDB development moving forward.

> For now, I don't have any practical suggestion for such procedures,

Like Tromey said, one way to do it would be to enforce opening a
documentation bug in bugzilla everytime an undocumented feature is
committed, and marking those bugs as release-blocking.

Then we should agree that a GDB release can only be made after all
blocking bugs are closed (boy I *am* smart, am I not?).

Another way to do it would be to add pending items to a GDB release wiki
page. Joel already uses this, in fact. So it's the easiest to implement.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center