Re: MI: frozen variable objects

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Nov 18, 2006 at 09:48:24AM +1300, Nick Roberts wrote:
>  > Is your concern breaking your MI frontend in Emacs?  If so,
>  > then you need to test - either routinely on HEAD, or if you have
>  > more limited time, then on release branches.  That's why we keep
>  > release branches around for a few weeks and announce prereleases.
> 
> If the changes go in after the release I generally have six months to spot a
> bug, if they go in now I'll have roughly two weeks.

I don't get the fuss.  It's not an immensely destabilizing change or a
huge new subsystem.  Why should it be treated separately from any other
patch posted in the last few months, in the later half of a release
gap?

GCC needs to enforce a three-stage system, but we don't.  We keep GDB
working from trunk pretty much all of the time.  I think we do, in that
regard, a great job.

> But I find something else anomalous about this.  Vladimir (on behalf
> of Codesourcery?) submits a patch for MI which has 26 hunks which
> you're proposing to approve in three days, just as a release is
> coming up.

Let me be perfectly clear about this.  I can spend a certain amount of
my work time reviewing community patches, because my employer is very
understanding about the FSF development process.  I'm lucky in that
respect and hopefully so is GDB.

I can spend a great deal more of my work time reviewing patches that
are directly to my employer's benefit and I do precisely that. 
Similarly I can spend much more time writing patches that are useful
to my employer (e.g. flash support) than I can on things I just think
would be good (e.g. several thousand lines of pointer to member
improvements that I still haven't gotten committed).  Don't
misunderstand me, I think the things I'm doing at work for GDB
are cool and good to have even in the FSF tree - otherwise we'd just
keep an internal fork.  But they tend to be of more use to embedded
developers than non-embedded because that's where we presently
have more customers.

I still spend both work and personal time reviewing GDB patches.  I
spend far more time than I want to doing this.  I'd rather be writing
my own patches.  Even so, the load of unreviewed patches far exceeds
what I can do on my own.  I have no chance whatsoever of keeping up.  I
have all your unreviewed patches flagged in my inbox, and I'll probably
get to them someday, but there are no extra hours in my day.

I am rapidly approaching burnout on GDB patch review.  I may stop doing
it entirely just to keep my sanity and have a little bit of my free
time back.

I appreciate that you fix things, especially those MI PRs.  I will
somehow get to them.  But, good lord, I need more help from other
maintainers!

And more maintainers.  All: Should Nick be an MI maintainer now?

-- 
Daniel Jacobowitz
CodeSourcery