Elijah’s Blog

So, I’ve been meaning to put these steps up online somewhere (besides release-team mailing list archives). I figured my blog was a good temporary place, at least. So, the instructions for gnome-2.12.0 would be:

1. Make sure you have the necessary pre-requisite packages

http://live.gnome.org/JhbuildDependencies may come in handy here. Note that it is okay to wait until you run into an error and then install the necessary package to avoid it, but it sometimes saves some headache to do it up front.

2. Download jhbuild (Note: just hit enter when asked for the password)

 $ mkdir -p ~/cvs/gnome2
 $ cd ~/cvs/gnome2
 $ cvs -d :pserver:anonymous anoncvs gnome org:/cvs/gnome login
 Logging in to :pserver:anonymous anoncvs gnome org:/cvs/gnome
 CVS password: 
 $ cvs -d :pserver:anonymous anoncvs gnome org:/cvs/gnome checkout jhbuild

3. Install jhbuild

 $ cd jhbuild
 $ make install

4. Create your ~/.jhbuildrc (or copy it from elsewhere)

 $ cd ~/
 $ wget http://ftp.gnome.org/pub/GNOME/teams/releng/2.12.0/sample-tarball.jhbuildrc
 $ mv sample-tarball.jhbuildrc .jhbuildrc

5. Build it

 $ jhbuild bootstrap
 $ jhbuild -m http://ftp.gnome.org/pub/GNOME/teams/releng/2.12.0/gnome-2.12.0.modules build

For other versions (greater than or equal to 2.12.0 since we didn’t start saving jhbuild modulesets until then, and didn’t start making them until much before then), just update the URLs accordingly. 🙂 Note that ‘jhbuild -m list -r’ can also be handy for finding out what version numbers occur in a given release.

Very interesting comments from the Mozilla guys on how they intend to clean up their bugzilla some. The most interesting parts, to me, were the statistics they had on usefulness of bug reports by age. It reminded me of a study I saw (no, I don’t remember it’s name or where I read it online) that talked about one of the advantages that open source has over typical proprietary development–namely that release early and release often provides more rapid feedback which enables faster development of the product and removes bugs faster. Of course, this can be offset by many different factors, but it was interesting to see the effect of this one factor. One thing I remember in particular was that the study actually had a suggestion for proprietary development to offset this disadvantage by ignoring bug reports against older versions of their products. Now granted, there are tradeoffs that need to be made in such decisions, but it looks like this Bugzilla work the Mozilla crew is doing is just an attempt to incorporate such tradeoffs to optimize their work instead of sticking with the extreme of keep-everything-open-unless-we-know-its-fixed. I’m wondering how/if similar things would work in Gnome and whether their measures for keeping the important old bugs open would be successful for us as well or if we’d have to do something different.

Well, it’s been a while since I blogged. Decided I’d try out the new blogs.gnome.org thingy. So, I totally don’t understand how the “Trackback URL(s):” field works. What is allowed to be added there and what does it change in the interface? I tried to play around with it before publishing this entry, but couldn’t figure it out.

Oh well. Maybe I’ll post something useful in my next entry and start blogging again slightly regularly.

So, I was really busy the last couple of months and I had much less
time to work on Gnome stuff. That’s understandable. But there seem
to have been a number of other factors trying to keep me from doing
anything useful in Gnome land as well….

For a while cvs hal/dbus (don’t remember which) depended on having a
kernel >= 2.6.10. Now, on my machine at school, I have partial root
privileges via sudo, but with the understanding that if I mess
anything up I no longer will have automated backups or the site access
to various software programs that I occasionally need. In other
words, I don’t touch system stuff like the kernel, or the versions of
any system administration programs or configuration (other than
occasionally temporarily mounting an iso image of an empty /usr/local
directory over the normal one to prevent the nasty conflicts of all
the junk they put in there while compiling Gnome). I tried messing
around with alternate versions of hal & dbus but didn’t have much luck
and since I didn’t have a whole lot of time anyway, I didn’t want to
waste my time on something stupid like that.

Now, the problem with the laptop is that it is pretty unstable. As
in, one of the sysadmins had to solder a board back together as it had
cracked/snapped (I don’t remember anymore what it was; perhaps part of
the motherboard or something) and told me I’m lucky it even works at
all. (This thing is definitely passed its warranty, so who knows if
it would work anyway…) This means that it often crashes/freezes for
no apparent reason. It makes compiling a development version of Gnome
on it somewhat painful.

At home, I have two machines–one for my wife, one for me.
Inexplicably, my machines seems to be freezing (hard) a lot. I have no
clue why. Most of it is relatively new too (had to replace a bad
motherboard, and decided to upgrade the processor and RAM while I was
at it since stuff as slow as what I had wasn’t really available. It
was a huge splurge considering our money situation, but since it was
around my birthday and we use both machines a lot…). Anyway, I
haven’t had time to try to figure out the cause other than that I
think it was more stable before I upgraded from FC2 (is the nforce
motherboard support in linux not good perhaps; would the nvidia
drivers perhaps help or make it worse?). This definitely doesn’t help
in trying to get Gnome compiled at all; crashing & rebooting after
building only two or three modules sucks.

On my wife’s machine, we have this *cough* lovely *cough* cheapo
Samsung ML-1740 printer. Ignoring it isn’t an option; my wife uses
the machine predominantly for school work so she needs to be able to
print things out. Samsung does provide their own drivers for this
printer and they even advertise that it works under linux, and these
drivers actually do work under a 2.6 kernel, but they really suck. As
in, after you go through the print dialog from whatever program you
are working in and pick all your options, it pops up its own print
dialog which has just as many options (and almost certainly in
different locations) for you to select–many if not most of which are
duplicates of things you just selected. I found at some point via
Google that it seems to work when you treat it as a ML-1710 using
system drivers instead of Samsung’s drivers. Much better. But one
day (after doing a whole bunch of system updates) it broke. Luckily,
my wife didn’t need it for a week and a half or so, but unluckily, it
wasted all my free time during that span as I tried googling like mad,
undoing lots of the updates, manually installing or removing various
drivers, unplugging the thing from the system and plugging it back in,
tweaking all kinds of system stuff, rebooting a few times for good
measure, and even installing three different distros versions on the
machine including the one she had before, before I finally figured out
at some point that the printer just refused to work until I manually
unplugged its power from the wall and plugged it back in. Black
magic, I guess. After that, it seemed to work regardless of what I
did. I really wish I would have thought to power off the stupid thing
sooner. I don’t know why I haven’t had to power it off since then,
despite doing a system upgrade (FC4) and changing a variety of other
things. *shrug*

So, my wife’s machine wasted lots of my time due to the printer, but
it also is generally a poor choice for a development version of Gnome
as she or my three year old daughter are often using it so that even
if I have time, the machine may not be available. Plus, her machine
is a bit slower, so it’s not as fun waiting for things to compile.

But that’s not all. No, that is not all. Apparently, the apartment
we are in has really old wiring or something such that it can’t
deliver all that much power. It turns out that having both machines
on at once is a fire hazard. No fire was actually started, but let’s
just say that one of the outlets (that nothing happens to be plugged
into, suprisingly enough) needed to be replaced and the electrician
did some line tests and told us we could only use one of the computers
at a time. Well, we might be able to use two, but then we couldn’t
use the air-conditioner that’s on the other circuit breaker. And the
landlord doesn’t want extension cords running all across the apartment
in an attempt to split up the load (“fire hazards” or something like
that plus some other lame excuses), and I probably wouldn’t want a
bunch of extension cords going into the kids room either (that’s the
only other room we could conceivably run an extension cord to and
considering where the outlets are and that I have an almost 1 year old
and a 3 year old, I don’t think it would work well).

Then, when a little bit of time starts freeing up, I get
labyrinthitis. My case isn’t as bad as others, or so I assume from
what I have read in my googling on the ailment, but it still makes it
extremely difficult to get anything done (I’ve had to split up writing
this blog entry into three separate efforts over two days now).
Naturally, this puts me somewhat behind on everything, and it may be a
while before I have some free time again. I really hope this
dizziness/headache doesn’t last much longer so I don’t lose much more
time.

Anyway, if you’ve been wondering where I’ve been or why I haven’t been
as involved lately (sorry Murray, I know I promised to have fixed
those gtkmm problems in my tutorial by now), perhaps this will explain
things.

So these Google
bounties look rather interesting. In particular, the global
memory analysis tool, improve
login time, and Gnome
architecture overview. Unfortunately, it looks like I’m
ineligible despite being a student because of the way it works (though
honestly, my fellowship’s requirements that “under normal
circumstances a fellow may not engage in work for renumeration during
the school term” and some other stuff (they attempt to explicitly
allow other work, but are trying to narrow down what kind and how much
and under what circumstances) would make it difficult to be
compatible, though I believe Novell’s bounties could fit if they
looked interesting–in part because of no necessary signup or time
period and in part because I can work on them during times other than
the “school term”). Also, it seems odd that the Bounty Contest Rules
page appears to be Novell specific and doesn’t mention the extra
requirements on the Google bounties (e.g. must be a student, must be
completed this summer, must signup by June 14th, etc)–making me
wonder if perhaps Google’s bounties might be obtainable under the same
rules as the ones for Novell, though I’m guessing it’s just an
oversight/mistake.

It seems that the global memory analysis tool bounty could be aided a
lot by
Soeren’s sysprof and the list of memory tools
here may provide ideas or getting started information.

But I’m really curious about the Gnome architecture overview, though.
In seems like
my guide could qualify (assuming I hadn’t yet written it and was
otherwise eligible for the program), though they probably want
something more like the
first section of chapter 5 of my guide being fleshed out (which I
had intended to do). But that seems curious in that I think the other
two sections of that chapter would be really helpful as well for the
audience they had. It additionally seems pretty odd because
Malcolm has already written something that appears to satisfy the
bounty criteria (though, I think Malcolm isn’t a student and thus
couldn’t qualify for the bounty…)–in fact, that was part of the
reason that chapter 5 of my guide was different; I didn’t want to
uselessly redo previous work. It really seems that this bounty is in
danger of repeating existing work…

Oh well, looks like my Gnome work continues to be for free. But, that
does have the advantage of incredible flexibility (e.g. who would make
a bounty for working on Bugzilla or on the bugsquad?) and has the
option to decrease the workload whenever I want or even drop it
temporarily when I feel overwhelmed or other matters start pressing.
🙂 And I look forward to seeing what cool stuff comes out of the
Google bounties and those who can participate.

Version Control System

It was nice to see
James writeup a
comparison of cvs, subversion, and bazaar. He concentrated on
showing the similarities, but I’d like to point out a couple strong
advantages bazaar would bring as a set of usage scenarios.

Usage case 1: If I’m working on a project hosted in cvs, I often just
won’t bother to hack on stuff if I’m forced to be offline. The reason
is that the lack of access to the repository is just so limiting that
sometimes I don’t feel like it’s worth it (I like to be able to look
for more details about a specific commit in the past, being able to
compare behavior to an old version, easily getting diffs without
having to remember to make a full copy of a pristine version of the
directory every time a cvs update is performed and/or hoping I
remembered to do it when I need it, etc.) This can partially be
solved in cvs by doing using rsync to make a copy of the repository
itself and to attempt to update it when I get back online (which I
have done), but it involves a bunch of hackery and is problematic at
best–it’d be too easy to totally mess up the repository. baz makes
it easy to replicate a repository and then merge between them. It’s a
very useful feature, even for a single-person project.

Usage case 2: When trying to fix a bug, usually in a product that I’m
not too familiar with, I often have several cycles of ‘cvs diff -pu |
less’ (to remember all the changes, extra debugging information I’ve
added, initial failed attempts to fix stuff that caused lots of
changes, etc.) followed by a number of changes to the code. With cvs
and products like gtk+, this is really slow and aggravating as cvs
diff takes forever. A local repository copy/fork/branch/whatever,
which baz enables, fixes this problem quite nicely. (Yeah, yeah, I
could check out another pristine working copy and just use normal diff
recursively on the two on-disk directories; yes, I do that with cvs at
times, but I usually think that “I’ll only need to do this one more
time…” and a full cvs checkout takes longer than a cvs diff)

Usage case 3: Lots of users with cvs are, of necessity, third-class
citizens–they only get access to the anoncvs servers which are always
out-of-date (even if only by a day) because there’s no way to give
them read-only access to the real cvs servers. baz can easily fix
that (my developing with gnome guide tutorial is in a repository where
only I have write access to, but the whole world has read access).

P.S. I don’t mention tla here even though it shares these advantages,
because its usability is so horrendously awful (IMO) that it could
easily be seen as negating all its advantages (at least the last
version I used). baz does suffer some still, but is far
better in the most recent versions. I’m really looking forward to
baz-ng to see if it can continue to improve the usability.

Bugzilla

I realized that although we had a few patch reports, I didn’t really
use them. I found that after I went to them to find unreviewed bugs,
I’d have to click on a link that would forward me to patch-status.cgi,
which would auto-redirect to buglist.cgi after some time, from which
I’d have to pick a bug (instead of a patch) and then scroll down to
find the patch and finally click on the appropriate links for it. It
was just too much of a pain. So, I wrote a new patch-report
(which other patch reports now make use of in their links). You can
also limit your search to
a specific product or limit it to patches created in a certain day
range such as
the last week.

Also, I was seeing multiple people suggest or talk about having a
special maintainer section that listed a bunch of common queries
(e.g. all bugs with patches that have been marked as
accepted-commit_after_freeze, or all bugs that haven’t been commented
on, or all bugs with a certain set of words in it, etc.). So I made
something like that at the reports
for maintainers section.

There seems to be an increasing amount of talk about “Gnome 3.0”, most
recently in comments by Luis and Dave.
It’s very puzzling. Reading these comments sounds like we’re somehow
failing or not progressing if we don’t do a 3.0. Yet none of the
comments seem to say that “here is something that we need in the
desktop and that we can’t do in 2.x”. In fact, many such comments
seem to state a bunch of things they’d like, but typically all the
concrete things they list can happen (at least to a large extent)
within 2.x. If I understand correctly, the reason for doing Gnome 2
was because there were a lot of concrete things needed that didn’t fit
in the 1.x framework. If we don’t have anything like that, and given
that work on a 3.0 would take a long time without shipping anything
and prevent people from getting as many incremental developments on
2.x, why would we even want to work on or think about 3.0 at this
point in time? Granted, I’m all for people experimenting and doing
cool stuff. And when we find something that’s cool that we don’t want
to live without and doesn’t fit in 2.x then we can work on a
transition. And I think that’d be good. But I feel like I’m missing
something fundamental because I don’t see any such things yet I see a
bunch of other people talking about 3.0 anyway. So what am I missing?

Also, Dave, you state that the 6 month cycle has outlived its
usefulness, giving the reason that 6 months are to short to get any
big user-visible features in a release cycle. While I agree that such
a time is too short for developing a big user-visible feature, I don’t
see why that’s a bad thing–big user-visible features can be developed
over multiple release cycles and then merged when it’s ready
(e.g. Luminocity and spiffifity). That even has the benefit of having
a shorter wait before officially shipping when it finally is ready.
Do you see the 6-month release cycle as just being to short to do the
final merge and testing of such features or something?

I have the feeling I’m missing something obvious that others are
seeing, but I really don’t understand a lot of what I’m reading…

So, when I decided to get involved in Gnome two and a half years ago,
I got a fair amount of advice and different directions to take on the
gnome-love mailing list. The main direction I picked at that time was
the one that had the lowest barrier to entry–bug triaging. I had
long since forgotten who suggested it (at that time, of course, I
didn’t know people in the community and names didn’t stick), but I
finally achieved his specific challenge–or at least what I
misremembered[1] his challenge to be. I just googled now to find that
original email so that I could fire off an email telling him that I
had done it. It was kind of bittersweet to see that it was Mark
Finlay that had sent
that email, since he’s not with us anymore; but it
was happy to remember all his energy and enthusiasm, and the work that
he put into Gnome.

[1] The misremembering that I had was two things: (1) thinking
“close/triage” instead of “fix” (but then again, there really hasn’t
ever been a list of top bug fixers), and (2) a switch in order of
“list” and “top” (amazing what a difference the order of two words can
make, eh? I guess it wasn’t so critical to get all those bugs closed
before the Evolution import after all…). Now, though, I think it’s
time to switch more towards “fix” instead of “close/triage”… 🙂

Luis pointed out
Olav’s awesome work on importing Evolution bugs to Gnome bugzilla
(Olav is also clearing out all kinds of bugzilla bugs and has some ambitious plans for
improvements which he has began work on). However, Luis, I have to
point out that the import won’t help you. Yes, your number of bugs
closed nearly doubles, but that actually drops you from 4th on the all
time list to 5th (you pass Kjartan just barely but gerardo and fejj
have closed an awful lot of bugs). Further, you will still only have
about half the number of bugs as the top bug closer…