Once again, Olav is kicking butt fixing bugzilla.gnome.org bugs. It’s
so cool. My favorite fix that he just committed recently is the handling of
needinfo bugs sucks problem.
Month: February 2005
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/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…
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
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. 😉
Metacity
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. 😉
Seth is the hero for the week
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 is today’s hero
Mark fixed
one of the most annoying bugs in Gnome. Yaay, Mark!
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
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.