Title? What title?

We’re actually in pretty good shape (hah) on 6.2. 6.2-RC1 has been built, uploaded, and announced, and kensmith@ released the code freeze for the RELENG_6 codeline. This means essentially that developers are free to begin merging work that will eventually become FreeBSD 6.3, although we do request that major changes be coordinated with re@ until 6.2-RELEASE is finalized.

On top of that, kensmith@ and I worked off (I think) all of outstanding MFC requests in re’s queue this morning.

I need to go look at some stuff with the recent 7.0 snapshots (announced by kensmith@ today). If for nothing else I need to update the CURRENT manpage set on www.freebsd.org (there used to be some part of this that was automated).

kensmith@ created the RELENG_6_2 release branch today. This is the codeline that re@ will be using to finalize 6.2-RELEASE. All of the release candidate builds, as well as the final release, will come from this codeline, and after 6.2-RELEASE, we’ll turn over control of this branch to the security officer team. They’ll then use it as a security fix / errata branch.

I was reminded today of how difficult it is to multitask well (in human terms)...basically I broke the release notes build by trying to give advice to kensmith@ and pay attention to a meeting at the same time. Bad Bruce, no cookie.

The 6.2-RC1 build should be happening soon (probably would have been sooner if not for the aforementioned breakage). It’ll have the latest round of fixes for em(4), and a number of other bugfixes and stability enhacnements. There are still a few more MFCs pending that will happen after this build, but the plan is that what’s on RELENG_6_2 now will be fairly close to what we ship.

Followers of FreeBSD events might know that a physical relocation of many of the main FreeBSD.org machines will happen this Friday. I wonder how many committers will be going into withdrawal as machines go off-line during the move.

jfv@ committed a new version of the em(4) driver that hopefully will solve the stability problems that various users have been seeing. This was the main blocking item for 6.2-BETA3 (kib@’s merge of devfs locking fixes was the other), so kensmith@ and others have started 6.2-BETA3 builds. After 6.2-BETA3 is announced we’ll see about revising the rest of the schedule dates, which I know concern a lot of people.

It’s been a month since I wrote anything for this blog. Time sure flies.

We’ve had two beta builds of FreeBSD 6.2 thus far, and we’re looking to do a third (hopefully the last before release candidates) real soon. There are several issues in play right now, mostly having to do with network device drivers. A number of users seem to have problems with the em(4), bge(4), and bce(4) drivers; some of the issues involved (particularly with em(4)) seem fairly difficult to debug. We need to get these addressed in some way and we’ve been holding up 6.2-BETA3 to get these under control. scottl, kris, glebius, and jfv have been working on this; they get my thanks however this turns out.

Since we added a new beta build that wasn’t on the original schedule, and it’s already somewhat later than we wanted, I’m pretty 6.2 won’t go out on November 13, or whenever it was that’s on the schedule. I think once we have a build date for 6.2-BETA3 we can revise the rest of the release schedule to be more realistic.

I’ve been looking at a lot of MFC requests the past couple weeks, partially because our head release engineer (kensmith) was off-line for two weeks, due to circumstances completely out of his control. This took me into some territory I hadn’t seen before. It’s kind of hard to evaluate some of MFC requests because they deal with parts of FreeBSD that I know little about (for example the virtual memory subsystem, or threading libraries). It helps a lot when a committer can give an honest risk assessment of what problem their proposed change solves, what the impact is, and how likely it is to cause regressions or other problems. It’s also useful to see a diff of the change, as well as all of the CVS commit logs related to the change. I know this sounds like a lot, but for a lot of MFC requests, this really isn’t a lot of information.

We need to be more responsive to people when the send to the re@ alias…we’ve dropped the ball a few times but we’re trying to do better.

bms@ committed a patch I submitted in response to a PR (bin/13691 in case anyone cares, filed back in 1999, with my patch submitted in 2000). This was way back before I got my commit bit, and back when I was a researcher doing analysis of traffic traces. The problem involved tcpslice, a program that used to ship with tcpdump that subsets a tcpdump file. tcpslice was written by an old friend of mine, Vern Paxson, and it’s quite clever in its implementation. Basically, the problem was it didn’t deal with >2GB files very well, and it wasn’t Y2K compliant. Both of these were problematic for a research project I was working on at the time.

Both problems have since been fixed in the original sources, and are reflected in the version that we have in the FreeBSD ports tree (I think it’s net/tcpslice). But for some reason we still have this really ancient copy in our base system. bms@ applied my patch, but he also wants to know if we should just kill the version in the base system. I think it should go away because heck, the Y2K bug made this program almost unusable and nobody (except for apparently a handful of us) noticed.

Anyways…it was kind of weird and cool to see this ancient patch hit the source tree.

(A little belatedly.)

I committed the first public draft of the 6.2 schedule to the www/ tree this morning. It’s not completed yet because we need to fill in doc/ and ports/ related items. Some of those are still being discussed. I almost could have filled in the doc items because doc tree slushes tend to be fairly informal, but wanted to DTRT and let doceng@ have their say.

It’s good to be working on releng stuff again (I approved my first two MFCs in over two years this week). I’ve been updating release notes a bit at a time (I tend to work on these in chunks of about 20-30 minutes or so).

The Web site has changed a bit (slight understatement) since I last had to deal with it; a bunch of files moved around and there are a lot more knobs than two years ago. Still it seems like it’s easier to make the changes we need to do around release-time and all of these knobs let us do them in a consistent way (so for example all of the release numbers change consistently throughout the site). simon@ gave me some good info on Web site building infrastructure.

Every so often, it seems like I need to make a pass through the release notes and clean up things, do some proofreading, and consolidate items. I’m doing that now, but unfortunately it’s going to be split up over about a week because I don’t seem to have any large chunks of “FreeBSD time” at the moment. It’ll get done eventually.

I finally have a machine running CURRENT…something I haven’t done since around 5.0. I’m running this inside Parallels on my Mac Mini. As a tip, selecting a machine type of “FreeBSD 5.X” seems to work just fine for 7.0-CURRENT (and very briefly for 6.1-RELEASE). Having virtualized machines like this is Very Cool.

I’ve been doing a few minor updates to the release notes the past week
or two. This isn’t necessarily really exciting stuff (writing the
updates I mean…the stuff they describe really is pretty cool). But I
like doing updates more-or-less as they happen, so I don’t end up
having to do a whole lot of writing during the release cycle.

The other way to approach the release notes is to save everything for
the end. The advantage of doing this is that you can see the context
for everything that happened during the release cycle. The downside,
of course, is that typically things get a little hectic in the stages
of the release. hrs@ prefers this approach, I’ve seen. I think it’s a
matter of preference.

I’ve been thinking of a couple changes I’d like to make to the release
documentation. The main one is to consolidate all of the
machine-dependent (MD) documents, so that there’s only one version of
the release notes (for example) that has annotations to call out
architecture-specific items. Originally I patterned the structure of
the release notes and hardware notes after a couple of text documents
that were maintained separately for the (then) two supported
architectures, i386 and alpha. This doesn’t necessarily scale very
well to the 5-6 architectures we now support!

I writing a quick-start installer guide a year or two ago that
combined all of the MD information; I found it was a lot easier to
edit than the multiple MD documents, mostly because I could print out
a single document with all the text. At some point I’d like to finish
off the quick-start guide, or if that’s not possible, hand it off for
someone else to finish.

So many things to do, so little time…

Speaking of which, I just checked the RE schedule…we’re only about
six weeks away from the start of the 6.2 release cycle!

As I’m sure many people are aware, the security team released two advisories today (they’re visible on the main FreeBSD site). The timing of some of this stuff forced us (re@) to hand-over RELENG_5_5 to the security team a little faster than we might have otherwise (so they could deal with patches for that branch). We try to cooperate as much as we can with secteam@, and in turn they give us hints about upcoming issues that might affect a release we’re working on. So it’s all good.

It’s been awhile since I had to deal with an advisory (SA-06:16 in particular) that affected four codelines (HEAD, RELENG_6, RELENG_5, and RELENG_4). So that was changes to four release notes and three errata files, plus some Web site updates. That’s a lot to do in a short time (admittedly a self-imposed deadline), but that’s probably nothing compared to the behind-the-scenes work that secteam@ had to do in order to devise and test the fixes (on over ten codelines, worst-case). So my hat’s off to them, as always.

The PDF output for the errata, specifically the table describing the security advisories, is unbelievably ugly. I remember discussing this with someone (hrs?) when this style of documenting advisories was first adopted, but at the time I was getting too burned out to care much (and neither of us had any good answers). Maybe we need to start thinking about this again.

We’re also thinking about some possible errata issues (non-security-related) to be fixed on RELENG_6_1 before handing it off. In some cases we’re waiting for the bugfixes to have proven themselves on HEAD and RELENG_6 first. I might try to at least write some of these items up for the errata document first, even if we don’t have fixes committed yet.