Elijah’s Blog

I’ve had a couple goals I wanted to help push during my time on the release team (r-t) to improve how things work: document the r-t processes better for other new members, make r-t processes more fail-safe, and make a few things work more smoothly (make it easier to build a development version of GNOME, make it easier to do GNOME releases, etc.). With the help of the team and the development community at large, I feel like most of these have been achieved. It took longer than expected and there’s always room for further improvement[1], but I’m very happy with the progress so far.

Anyway, I think it’s definitely time for a change; I’ve been in my role for a couple years now (about a year longer than I initially thought I would be). As I mentioned on d-d-l, I’ve proposed to have Vincent take the reins as the release team manager. Some of you may have thought he already was given how active he always is; it’s really hard to keep up with him. I’ll still stick around on the team and help out for now, but it’s time to switch roles and I think vuntz will do a wonderful job taking over the reins.

[1] I particularly like and agree with Owen’s suggestion to create standard jhbuild configurations.

Rather interestingly, the subject of DSCMs[1] has come up on various GNOME mailing lists.  I’ve always been peripherally interested in them, and have read at least several dozen articles/blogs/howtos/comparisons/etc. on them.  I even tried one a number of years ago, but unfortunately picked a horribly awful one that was so amazingly painful to learn and use (in more ways than you’d think possible)[2] that I’ve avoided adopting any others for a long time.

Now, I have made very basic use of both bzr and git in the past (only used a subset of the basic features of each) — but both were some time ago.  I’ve heard that both have changed quite a bit since then, which is good, or neither would be fit for use.  (bzr was painfully slow even on small personal projects, and git was beyond unreasonably complex to attempt to learn.)

So, between the recent interest in both the GNOME and the KDE camps, and wanting to find something nice to advocate replacing CVS at work, it’s probably time for me to start learning some new version control systems and making my own comparison so that I can participate intelligently in the discussions.  cvs, svn, git, bzr, hg, and possibly others, Oh My!  (That doesn’t have the same ring as “lions, and tigers, and bears!  Oh My!”, does it?)

[1] Distributed Source Content Management systems, though I dislike the name as it is somewhat misleading. It implies that the systems must be used in a decentralized way, when in reality the difference is that these version control systems come with distributed capabilities as well as centralized ones. Xorg is an example that uses a DSCM in a largely centralized way (or at least was), and that’s how I’d expect GNOME to use it and most users to use them (at least at first).

[2] The system was tla (and baz), for the curious.

For those that noticed, sorry for having disappeared completely this past week. I was under the weather with bronchitis. I could hardly even eat or walk on Monday, and am still a way off from 100%. If you’re waiting on me for anything…you may be waiting a while.

The good news is that despite being the final week before the big 2.20 release, there seems to not have been a single hiccup with the release process. (Granted, I’ve only had the energy to do a little reading/responding and I still have a huge email backlog, but everything looks encouraging that I’ve seen.) Many thanks to all the release team members who stepped up and took over the slack. It’s very encouraging that if any one of us suddenly goes out of commission, there are others on the team who are willing and capable of taking over and ensuring things get done.

For my birthday, I bought a nice new LCD monitor (it’s sooooo nice to not be a poor graduate student anymore…). A Samsung SyncMaster 204B. In addition to being a cool monitor, it also confirmed my slowly-formed theory about the source of the headaches I was frequently getting at nights and on weekends. It’s nice to finally be headache free again. However, there is a downside. Despite the extra cash I paid to get a monitor with 1600×1200 resolution and the extra time I had to spend to find such a monitor, Fedora 7 insists on running it at 1280×1024 or lower. ‘xrandr -q’ only lists resolutions at or below 1280×1024.

I went into system-config-display and selected “LCD Panel 1600×1200″ and restarted X, but no luck. xrandr still doesn’t allow 1600×1200. I’m not that familiar or comfortable with xorg.conf, but I tried a couple things (explicitly adding a Modes line with the entries “1600×1200″, “1280×1024″, etc; modifying the HorizSync and VertRefresh to more closely match the specs I found online). No dice. I tried googling a bit and saw some Debian post about deleting one of the existing modelines, but my xorg.conf has no modelines and I’ve heard scary things about editing them and what can happen if you get it wrong. I feel like such a noob.

To Summarize: How do I get Fedora 7 to run my Samsung SyncMaster 204B at its native (1600×1200) resolution?

Thanks in advance for any pointers.

UPDATE: To answer some questions: I have an nvidia card (Quadro FX 1400 as far as I can tell from lscpi) and am using the nv driver. Also according to lspci, the video card seems to have 128MB memory. I’m using the DVI connection between the monitor and video card. System RAM is 2GB. Also:

[root@Eenie ~]# cat /var/log/Xorg.0.log | grep 1600×1200
(II) NV(0): Modeline “1600×1200″ 161.00 1600 1712 1880 2160 1200 1203 1207 1245 -hsync +vsync
(II) NV(0): Modeline “1600×1200″ 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync
(II) NV(0): Not using default mode “1600×1200″ (exceeds panel dimensions)
(II) NV(0): Not using default mode “1600×1200″ (exceeds panel dimensions)
(II) NV(0): Not using default mode “1600×1200″ (exceeds panel dimensions)
(II) NV(0): Not using default mode “1600×1200″ (exceeds panel dimensions)
(II) NV(0): Not using default mode “1600×1200″ (exceeds panel dimensions)
(II) NV(0): Not using driver mode “1600×1200″ (exceeds panel dimensions)
(II) NV(0): Not using driver mode “1600×1200″ (exceeds panel dimensions)
(II) NV(0): Not using mode “1600×1200″ (no mode of this name)

Anyway, the first handful of suggestions didn’t pan out, but I’ve got about a dozen more in the comments to this blogpost, so I’m going to be trying some of them out. Thanks to everyone so far with suggestions.

UPDATE: Thanks to everyone for the many additional suggestions.  Apparently no amount of xorg.conf tweaking will fix this issue.  As nona and ajax pointed out in the comments, this is apparently a limitation of the nv drivers.  (See freedesktop bug 3654 and bug 4314) Apparently the workarounds are to either use the proprietary nvidia drivers (yes, I do feel a bit icky right now; and worried–they haven’t been very stable for me in the past) or use the VGA connection instead of DVI (which now that I’ve been made aware of, I might be soon switching to this).

It is nice to have the native 1600×1200 resolution now.

Got GNOME 2.19.4 (finally) and 2.18.3 out the door today. The hold up on 2.19.4 was finally resolved today, allowing us to fulfill the claim that the release would be made on Wednesday. Two releases to celebrate independence day.

So, guenther notes that I’m running a bit slow getting the release out. And yes, it’s Thursday in UTC time already. I’m working on it now; it’ll be out before long (assuming the few remaining issues are easily resolvable).

As for why I’m not ready yet: I was trying to work on the release yesterday, but ran into a few issues. GNOME websites were almost completely unresponsive yesterday evening when I was trying to work on the release (lots and lots of timeouts yesterday, and I couldn’t ssh in either). Further, I had to wait for the new gtk+ and glib releases since issues were discovered with the original tarballs meant for the 2.19.3 release (Matthias rocks for making the new tarballs so quickly, however, since I can’t work on the release while I’m at work, it would have been nicer if he hadn’t released the tarballs right as I’m driving to work in the morning and making me look like an even bigger slacker when I’m slow to respond).

I’m now in my second full day of being homeless. Yep, the movers came and packed all our stuff away, and we don’t sign on the new place in Albuquerque until next Monday. We’re using the time inbetween to drive our families crazy and make them be happy that we’re leaving.

So I’ll be offline or only briefly online for a couple weeks. Hopefully no critical Metacity bugs are uncovered between now and then (oh, and distributors should feel free to ping seb128 for IRC conversation logs regarding bug 433253 if need be).

I’m kind of surprised that John was attracted to GNOME based on a meaningless, confusing backronym (and even more surprised by his dramatic change of opinion), but I’m glad we got him either way.

i finaly done gradeeated! Ain’t no one can say im an uneducated fool. They have to drop the adjective now. It’s time for me to bid a fond farewell (good riddance!) to graduate school.

In about a month, I’ll be moving to a magical, far away place where the sun is always shining and the air smells like warm root beer and the towels are oh so fluffy to start a new job. The job search took longer than I expected, but I ended up being really lucky. I had four favorites from among the list, and I hit a jackpot: got offers from three places, all from among those top four. I had a hard time choosing between them, knew that I’d be second guessing myself regardless of which one I picked, but ended up picking the postdoc position at Sandia National Laboratory last month (despite being a temporary position–maximum 6 years). I’ll be in the Thermal/Fluid Computational Engineering Sciences Department. It’s time for an exciting adventure!

I guess this means I’ll have to be removed from the Utah Open Source Planet, but GNOMErs should definitely expect to see me remain involved in GNOME. I’m sure the new job and home ownership will have some affect on how much I can be involved. I don’t know how much yet, but I do know that I’ll still be around. I’ll play it by ear and resign from some of my responsibilities when/if needed.

…and will be for the rest of forever. The hard code freeze is lifted with the .0 release, but API/ABI, feature, UI, and string freezes remain in effect.

It appears we (the release-team) have failed to communicate that any API/ABI, feature, UI, or string change or addition for the stable branch needs to be approved. I’ve been surprised multiple times in the past (most recently today) that there are developers who do not know that most freezes remain in effect after the .0 release goes out the door. This includes some pretty core hackers. Does anyone have suggestions on how we can make sure to get the word out better? (We’ve mentioned this fact on the 2.17 schedule next to the 2.18.0 release, on the new live.gnome.org/Schedule (which in general is the fastest way to get a reminder of which freezes are active during any cycle), and we have sent reminders in the past to devel-announce-list.)