On Mon, 29 Mar 2010, Jason Wessel wrote:
>
> Ping.
>
> Linus, please help me understand how we can continue to move forward on
> the kernel debugger pull requests. There have been numerous requests
> that have not been pulled and have no response as to what needs to be
> acted on to resolve any outstanding issues.
I've been swamped and bad, and since I wrote another email to explain why
I'm always so grumpy (unrelated thread, nothing to do with kgdb), I'll
cut-and-paste some of the relevant explanation for my pulling (or not
pulling, as in this case) here too..
--> begin cut-and-pastee <--
Even on the merging side, what ends up happening is that some trees I
decide I can't afford to merge, simply because the potential pain of
merging without knowing the code is too high. So I can merge a new
filesystem without any issues - if it's buggy, all I need to know is "new
filesystem craps out". But when it comes to core generic code that anybody
can hit, I have to _rely_ on submaintainers doing the right thing.
And when that doesn't work out, and stuff falls through the cracks, I'm
kind of screwed. And this looked like a "fall through the cracks" thing.
[ I skipped the kdb merge this window, for example, and I feel bad about
that, and will have to walk over the pull request with a comb once the
merge window fallout calms down, so that I can do it the next merge
window. Not because I need to understand each line, but because I
need to understand what the potential bigger-picture impacts are when
something that looks odd pops up ]
--> end cut-and-paste <--
and obviously one of the issues is that I end up always prioritizing my
pulls etc, and because I'm not a huge fan of debuggers (understatement of
the year), that pull request was always at the bottom of the pile. And
this merge window I ended up having some Intel event things that took up a
good chunk of the window, so I never did get to that bottom.
Usually things calm down for me at around -rc4, when it turns into a
waiting game instead of fighting fires. So I'm expecting to do that "look
things over" this weekend or next week.
Linus
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Kgdb-bugreport mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
