tla and baz

I just gave bazaar a try today. It definitely looks nice, but one of
the main things I was hoping to get was a non-braindamaged diff
format. baz uses ‘baz diff’ instead of ‘tla changes –diffs’. This
is both easier to type and easier to discover…but it’s really lame
in that it doesn’t accept any of the normal options to GNU diff. This
is very counter-intuitive to me. In particular, there’s no way to get
it to show which C/C++ function each change is in (which would be done
by the -p option to GNU diff).

Of course, tla and baz
do make sure to take care of me by making it possible to get anything
I want done. Behold:

tla changes | grep "^M" | colrm 1 3 | xargs -n 1 -i diff                    \
-pu \{arch\}/++pristine-trees/unlocked/simple-iim/simple-iim--main/simple-ii\
m--main--1.0/{} {}\
| less


baz status | grep "^ M" | colrm 1 4 | xargs -n 1 -i diff                    \
-pu \{arch\}/++pristine-trees/unlocked/simple-iim/simple-iim--main/simple-ii\
m--main--1.0/{} {}\
| less

I would really like something that is, um, a little easier to remember
than these commands. Anyone know how to do this in a more simple
manner? I’d really like

  baz diff -up

to work. (Yes, the -u would be redundant since tla and baz made the
smart move of making unified diffs the default, but I’m used to typing
it anyway for CVS)

Update: Got a solution from Crispin. Create a wrapper called
‘diff’ which just does an ‘exec /usr/bin/diff -up “$@”‘, and make a
~/.arch-params/path file which contains the output of $PATH, but
prefixed with the directory where this wrapper resides. Works for
both baz and tla. Just a hack, but it’ll work fine until tla and baz
get their act together…

A rift in the fabric of time has occurred

I just moved up a position on the list of top bug closers for all time
in b.g.o. Whee! (Don’t know how long it will last when a certain
someone sees this post and decides to go crazy and close another
couple hundred bugs; especially since he only needs to close three to
pass me back up…)

Just 901 more bugs (currently, anyway) to go to pass up the next person…

Follow up on the spam problem

Got an email from Ryan McDougall about my previous d-d-l spam
post. He points out what he wrote at a page on
, which definitely have good ideas and which would
definitely help. While we have tried similar stuff before (I’m really
glad Mark worked so hard at this last year and was disappointed that
others such as Alan flamed him for it); renewing the push to do this
would definitely be good. I think we should do it. But it really
isn’t everything I want either. There are many emails that would be
considered on-topic on d-d-l but which would just be considered spam
to many who would otherwise want to be subscribed to d-d-l. Some

  • freeze break requests are rarely relevant to more than a couple
    people outside a given module; those who want to follow those could
    subscribe to d-d-l or read the r-t archives instead of the “filtered
    d-d-l” list I had in mind
  • threads about work on a single module don’t appear to be
    considered offtopic in many cases (and it’s often hard to tell the
    fine-line between offtopic and ontopic for those). Since there are
    many who would not want to have to see any of them that aren’t
    directly related to the module they are working on, I don’t think
    these should appear (other than maybe in summary form) on the
    “filtered d-d-l” list I was thinking of. (threads that affect more
    than one module, assuming that there was no other relevant mailing
    list or place to discuss, should be allowed on the “filtered d-d-l”
  • consensus threads are ontopic for d-d-l, but are huge and many
    people working on just one module and merely want to know the basics
    of what is going on don’t care about these (these exact threads have
    been the final reason to cause me to unsubscribe from d-d-l more than
    once in the past because I just couldn’t keep up and hated manually
    filtering–yes, I resubscribed later for various reasons). One or
    more summary emails would be much better for many people
  • Some threads are more than just on topic on d-d-l, they’re sorely
    needed (think of the ARC discussion and providing better stability for
    3rd party developers; this was one of the coolest recent threads on
    the list). But these can still be extremely long. Again, many
    who are only working on a single module and merely want to keep a
    basic idea of what is going on would be much better served with a
    quick summary (or summaries since it may be nice to point out the
    thread early on with occasional updates considering its importance)
    and a link to the thread on d-d-l.
  • When people post things who don’t know the rules, everyone ends
    up getting at least two posts that aren’t useful to them: (1) the
    original email, (2) the email directing that person where they should
    ask the question. That’s fine on d-d-l. I would like a list where
    you don’t have to see that, because d-d-l is just too high a volume
    for many, many people to follow. Again, a “filtered d-d-l” list seems
    that it would do the job nicely

Now, of course, there are likely technical issues or other problems
with the ideas I had in mind. I’m not a gnome-sysadmin. I have no
important role with mailing lists (well, other than moderator for
gnome-bugsquad and bugmaster). I don’t even understand much of how
they work. I’m not interested in doing the work necessary to
implement my ideas (I would be, but it sounds like a lot of
effort…). If I had the experience and thought the ideas were sound
and I was willing to put effort where my mouth was, I would have
posted on d-d-l instead of in my blog. You need not worry about my
ideas on this topic. ;-)


Since there have been a lot of bug fixes to Metacity since Gnome 2.10
Beta 2, and because I have learned that lots of bug fixes usually
means at least one new bug accidentally introduced, I made a
new release
today hoping to get some wider testing of all these
changes a week before hard code freeze. So try out the new release
(or update your CVS build). Otherwise, the only other Metacity bug I
plan to fix before 2.10 is bug 167630.

Update: Sebastien already packaged and uploaded the new version
for Ubuntu. Sweet!

Dealing with the d-d-l spam problem

I don’t know if it’s just the pessimist in me, but considering the
efforts before that have failed at controlling the d-d-l spam, I
started wondering whether the recent one will work over the long-term
either (I don’t see the difference between this attempt and previous
ones). So, I spent a little time trying to
think up a solution
. This may not be feasible (why worry about
petty technical details when trying to think of a good solution?), and
may be a really stupid idea anyway (it’s just my brain dump from an
hour or two), but I’m posting it here so the world can have a laugh at
my expense. After all, I always appreciate it when others make me
laugh, so I thought I’d try to return the favor–although in a perhaps
slightly different way. ;-)

Kjartan and Matthias are today’s heroes

A few days ago, Kjartan roped me into trying to look at the massive
problems we were having with themes. It turns out that by changing
your themes around in gnome-theme-manager, you could cause random apps
to crash. We got libwnck, gnome-terminal, metacity, gnome-session,
and a whole host of other apps to die that way. It seemed to
especially like killing gnome-session for me, killing everything I was
working on and making me relogin–almost every time I tried looking
into the bug. Anyway, Kjartan and Matthias found the issue
and fixed
. Wahoo! You guys rock!

Time to move on to the other

Update: If you’re a theme engine developer, Kjartan’s ChangeLog
entry is worth reading:

* engines/smooth/src/engine/smooth_gtk2_engine.c:
(smooth_rc_style_parse): Use g_quark_from_string() instead
of g_quark_from_static_string() since the latter will cause
problems when used in modules that are dynamically loaded
and unloaded. This should solve a ton of crashes related
to changing themes. Closes bug #165942, bug #166018,
bug #160803, and is also related to other theme related
crashes all the way back to 1.4.x. Theme engine authors
should be made aware of this so we can get external theme
engines fixed.