tytso at MIT.EDU
Mon Jun 30 03:45:08 PDT 2008
On Sat, Jun 28, 2008 at 08:06:03PM -0700, Ulrich Drepper wrote:
> Basically everything you say is incorrect:
> - - there are regular snapshots; they are done automatically every
> weekend. They are meant to e usable
> - - the project is simply moving fast to make "stable" releases not really
> useful. Snapshots are meant (for now) to be the way to use the
How is "fast-moving" and "automatically generated snapshots every
weekend" and "meant to be usable" supposed to go together? Systemtap
is (I thought) a mature project --- at least everyone tells me that.
It's certainly been around for years. Normally releases get tested
and there are release candidates to make sure that someone hasn't
checked in a massive regression friday evening at 4:45pm before going
home for the weekend....
Another thing which is not clear is if Systemtap is so fast moving, is
a bleeding edge version of Systemtap required? Since there are no
release notes with weekly snapshots, it's hard to tell if (for
example) the 20071201 version of Systemtap that comes with Ubuntu
Hardy is recent enough. Or how it relates with the Systemtap 0.6.2
version that ships with FC9
I would hate to waste hours trying deal with some weird behaviour in
Systemtap, only to be told --- oh, you were using too old of a version
of Systemtap; you need to upgrade to the latest. "Fast moving
project, you know."
News flash: Git supports maintenance branches very easily, and it's
not hard to commit bug fixes on the maint branch and then pull them up
development branch. Speaking of git, Junio supports git on a
part-time basis, and judging by the commit rate, git as a project is
far more fast-moving than Systemtap, and yet Junio manages to do
regular maintenance releases every 3-4 weeks and major releases every
six months, with proper release notes. So I'm going to have to call
bullshit on the notion that Systemtap is "too fast moving" for regular
 In the last month, Systemtap has averaged 22.75 commits/week. Git
has averaged 100 commits/week. And with a part-time maintainer, git
has had 3 major releases (1.5.4, 1.5.5, and 1.5.6) and 9 maintenance
releases since the beginning of the year, all of which have very nice
release notes so you know what is in each major and minor release. In
the same time, Systemtap has released *one* release, 0.6.2, and
curiously by what **must** be a coincidence (since I am *not* claiming
that Red Hat is evil), it's what is used in Fedora Core 9....
> - - you need no special elfutils. There are no API changes at all in
> the versions used in systemtap. The patches which Roland added are
> simply not necessary for usable distributions or are adding just more
> overhead through additional tests
Really? That's not what the official instructions in the source tree
- Untar the snapshot in some new directory; apply patch (don't ask, long story)
And other people have told me that you *must* apply the patches or you
will be tearing your hair out. (Gee, thanks for the tip. Glad I
found out ahead of time...)
Stupid question ---- if systemtap needs the latest bleeding edge
elfutils, specially patched, why isn't there a way to just drop the
libraries into the systemtap source tree and compile them statically
into the systemtap? It would massively increase the ease of someone
who wants to just pick up systemtap and try building it from source.
> - - Insinuating that Red Hat does something evil with the releases is just
> a sign of your hostility and paranoia. Why should RH have have any
> interest in stifling the success of the project? As the web page
> says, snapshots should be used. If a specific version number is
> attached to a snapshot this has no significance at all.
> If you have problems getting a recent systemtap release blame your
> distribution maker. The Fedora package maintainer (who happens to be
> part of the systemtap team at RH) makes releases.....
I'm not insinuating that Red Hat is doing anything evil --- just that
the systemtap developers are being incredibly, incredibly
short-sighted. Look, the fact that you say, "if you have trouble
getting a recent systemtap release blame your distribution maker"
means that you admit that special work needs to be done *by* a
distribution to get the latest version of Systemtap working on a Linux
system. This is insane, if you are expecting random kernel developers
to help out Systemtap by creating tapsets.
In fact, if (as you say, and I agree) Red Hat's interests are best
served by making Systemtap successful, and kernel developers are
needed to help create tapsets, then the Systemtap project developers
should be *helping* to make it easy to install Systemtap on other
distributions --- and not using the line "blame your distribution
maker". If Systemtap is harder to use than "download; configure;
make", then something is wrong.
> The point is that this is a tool developed mostly (almost exclusively)
> by people who know development tools. Lots of problems have been
> discovered and fixed by them (including lots of problems in the debug
> information generation in gcc, an ongoing project). But there is
> limited knowledge in kernel activities so the sophistication of the test
> cases written by the group itself is low. For sophisticated cases the
> group relies on outside contributions.
Well, in that case, it needs to be easier for people to pick up and
use Systemtap! Not all kernel developers use Fedora.
> As I mentioned before, it might indeed be the right idea to keep the
> tapsets and tapscripts along with the kernel. Kernel developers are the
> best people to get this done so you won't need help with this.
Indeed, and possibly in we will need to include some parts of the
tapsets in header files, so that when data structures get updated,
there is some chance in heck that the tapsets get updated as well.
More information about the Ksummit-2008-discuss