Elijah’s Blog

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/newren@math.utah.edu--amr/simple-iim--main--1.0--patch-60/{} {}\
| less

or

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/newren@math.utah.edu--amr/simple-iim--main--1.0--patch-60/{} {}\
| 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…

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…

Got an email from Ryan McDougall about my previous d-d-l spam
problem post. He points out what he wrote at a page on
live.gnome.org, 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
examples:

• 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”
  list)
• 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!

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. 😉

Previously, I’ve blogged about heroes for the day because they solved
showstopper bugs for the next Gnome release. Seth did something much
better. He provided a
solution for a showstopper to the Gnome community. He also
slew one of the worst heads of the beast. Three cheers for Seth!

Mark fixed
one of the most annoying bugs in Gnome. Yaay, Mark!

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
it. Wahoo! You guys rock!

Time to move on to the other
showstoppers.

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.

A few months back, Daniel ran a
full gnome session under Valgrind. He did so with a Fedora 3
system but without debuginfo packages installed. So, I used his
instructions on my cvs build. I found out that it was a royal
pain to sort through all the log files that valgrind generates when
you’re done. So, I didn’t do it again for a long time.

I finally got off my lazy duff and wrote a script to
assist in valgrinding Gnome. This script makes it easy to set
things up so my next sessions would run under valgrind, parse all the
generated logs to chuck out the bad ones and generate
a pretty statistics report, and clean things up and sets things back
to running without valgrind for subsequent logins.

I know, I know. I should have been working on the focus bugs (sorry
for my slowliness Christian in looking at your Epiphany patch–I’ll
get on it soon) or updating the modules that use gnome-desktop to
launch apps but…I’m a volunteer and I do whatever I want. 🙂
Anyway, take a look at the
statistics and the linked-to logs (with line-numbers!) and see if
you can fix anything. You’d be my hero if you could fix the
uninitialized warnings for Metacity, especially the ones that include
the meta_frames_ensure_layout function. 😉

So far this month, there have been more than 1000 more bugs closed
than what have been reported (3859 versus 2822). It’s usually pretty
rare for us to even keep up, let alone do a massive cleaning like
this. So, if you closed any bugs this month, give yourself a pat on
the back. This was a joint effort by lots and lots of people.

Looking closer into the large number of bugs closed, there are 10
people who are on track to close over a thousand bugs by the end of
the year if they can keep up their current rate. (In particular,
Sebastien has well over 500 already! Go Sebastien!) For comparison
purposes, there were only 12 people who were able to close over a
thousand bugs when
2003 and 2004 bugstats were combined. Granted, it’s very unlikely
this crazy pace will continue, but it’s still awesome to look back on
the month.

And the icing on the cake is that Metacity is no longer on the weekly

bug summary. It’s just not buggy enough anymore, I guess. 😉