This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Implement -exec-jump
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