Archive for October, 2006

6.2 Progress

Tuesday, October 31st, 2006

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.

FreeBSD 6.2 continues

Tuesday, October 24th, 2006

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.