Re: MI: frozen variable objects

Daniel Jacobowitz
2006-11-17T21:05:14Z

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