Re: Discussion at Linux Foundation Japan Symposium

[Roland McGrath <roland at redhat dot com>]

> > The process of getting userspace probes in will go slowly (if at
> > all).  I haven't seen a new version of the patches submitted in
> > months --- and the 2.6.29 merge window will be opening soon.  [...]
> 
> Roland?  Please advise.

I've never had much facility for soap opera, so I'll ignore Ted's
hyperbole about my personal ability to relate to the kernel community.
I think my record of kernel contributions speaks for itself (for however
good or ill you construe that record).  But it's worth noting that of
the 231 upstream commits since 2.6.24 that GIT attributes to me, only a
handful are *not* part of the groundwork for utrace (or whatever it may
become or be supplanted by).

I believe the actual reasons for slow progress are far more mundane than
any dramatic intercommunity conflicts or failures to address the kernel
development culture.  It's the variety of effects of having ~0.5 person
ever work on the core enabling piece (utrace) that has to go in to
enable other work.  (And 0.5 of a bit of a scatterbrain, at that.)  As
I've seen it, there has been a great deal of hand-wringing and fret, and
some amount of blame-seeking, but not a lot of straight-up collaborative
hacking.  I consider this an organizational failure of the project's
community and the organizations supporting it, of which I'm a member and
a party to that failure.

I'll freely admit to being disappointed about that, but I don't see any
point in dwelling on any past lacks--I'm sure I'm lousy at discussions
hashing them over, and I'm sure I have no patience for them either.  We
simply have to work harder and more cohesively together to make progress
now, and I think we all know what it takes to do that.  
Less yakin', more hackin'.

We recently had a meeting (among several main systemtap contributors) on
this.  I did not then characterize the situation in such stark terms,
but we discussed how to collaborate better on utrace and related code
that we need to get in shape to go into the kernel.  (Some notes from
that meeting were posted on the utrace-devel@redhat.com mailing list,
and I'm not sure if those were posted here too.)  I can only hope that
when we resume work in the new year, we'll have turned over a new leaf
and see contributors driving hard and participating with gusto in every
aspect of the kernel work we need.

This will certainly be a test, as it comes in a context of less than 0.5
of my time allocated to kernel work in the coming period that will cover
at least the next one or two kernel merge cycles.  Progress on utrace
has been regrettably slow this fall, and it will get even slower now
without major collaboration.  (It so happens this refocusing of my time
is intended to jump-start the DWARF size reduction work.  I won't deny
this may well be "12-18 months out" for stable release deployments, but
it can't even be that if it doesn't start sometime, and this is an
approach to the debuginfo issues that most people other than Ted seem to
agree could solve many important problems for systemtap.)


Thanks and Happy Holidays,
Roland