On the 6 and 7th November 2010 will be run the first NetBSD Hackathon in Paris, France. The event will be held at ESPCI Paris.

Everybody that has an interest in NetBSD, from developers, documentation writers, translators, to advanced users, are invited to attend.
If you just want to come and discuss NetBSD with some NetBSD enthusiasts, you are also welcome.

The idea is to take this opportunity to meet with the French and French-speaking NetBSD community, for a hacking week-end: contributions to src, pkgsrc, xsrc, wiki, documentation in French on NetBSDfr wiki, submitting or closing PRs, etc..
Let's meet on Saturday, November 6th, starting at 9 am in ESPCI Paris Tech (thanks manu@ for hosting us).

If you wish to join us, please send a mail to guigui _AT_ netbsdfr _DOT_ org (as we need to provide a list of attendees in order to get access to the ESPCI premises).

NB: Accommodation and food will be the responsibility of the attendee. However the organisers are currently looking into a meal at a local restaurant on Saturday night.

Please help us test this release candidate as much as possible. Remember, any feedback is good feedback. We'd love to hear from you, whether you've got a complaint or a compliment. That said, we hope your feedback is positive, as we would like this to be the final release candidate before 5.1.

With this post, I would like to announce the availability of the atf tutorial published on the wiki!

This new document intends to aid NetBSD developers in writing atf-based tests for the NetBSD source tree. It does so by providing a description of the basic concepts behind the atf design and listing what the necessary steps are to write an atf-based test for the NetBSD source tree. The tutorial also includes several code snippets ready to be copy/pasted into your own code, some reference sections for common functions and a short FAQ section for common concerns raised by users of the framework.

The tutorial comes to fill an important gap in achieving wide acceptance of atf among NetBSD developers. Some of us have been trying to migrate old regress tests to the new atf framework for a while, but such efforts are futile if other developers keep submitting new tests to the obsolete regress tree. However, such developers have been doing so because the atf documentation is not yet up to the task to guide a new developer into writing a test program for NetBSD. I expect this new tutorial to cover this gap and I hope you enjoy reading it as much as I enjoyed writing it. Comments will be highly appreciated!

Lastly, I want to give special thanks to Antti Kantee for the multiple rounds of reviews and suggestions on the text.

There are numerous good tools which do an excellent job of testing
kernel features and help to catch bugs. The more frequently they are
run as part of the regular development cycle, the more bugs they
expose before the bugs are shipped to be discovered by end users. However,
prior to being able to execute kernel tests configuration is
required. Examples of configuration steps include mounting the
file system under test, setting up an NFS server, selecting a
network interface and configuring an IP address or setting up a
test network. This makes taking a kernel test suite into use
unnecessarily complicated and reduces the likelihood of all tests being
run by any single kernel developer as part of the development
process, thereby reducing the number of bugs which are caught early on.

This article explains how rump is the enabling
technology for a safe, fast and run-anywhere kernel test suite
which requires absolutely no configuration from the person running
the tests. We will look at various kernel
tests, such as those related to file systems, IP routing and kernel data structures, and
point out the advantages of using rump as compared to conventional
testing approaches.

Zoltan Arnold NAGY has been busy coding away on his project to add support for booting over HTTP to libsa. Early on in his work he found that the current libsa PXE support used the UDP support functions in the PXE ROM which is unsuitable for HTTP as this requires a TCP transport. Zoltan has written a net_if driver for libsa that uses the PXE UNDI functions to allows both UDP and TCP network packets to be sent. Using the new net_if he was able to boot a kernel using tftp which proved that the basic networking functions were working correctly.

Once the underlying network layer was available Zoltan moved on to the primary aim of the project, booting over HTTP. He has made good progress on this and reports that he can boot a kernel three out of four times via HTTP, clearly one of the goals for the remainder of the Summer of Code is to get this to a 100% hit rate for booting.

There is still a fair bit of work to be done but I believe that Zoltan is on track to providing a useful factility to libsa. Zoltan posted a link to his patches in a posting to the tech-net mailing list

The last interview, Christos', is almost 08 months old.
For the first interview of this year, Thomas Klausner, also know as wiz@, has accepted to answer
NetBSDfr team's our questions.

NetBSDfr: For those of our readers that don't know you, can you introduce
yourself ?
wiz: I'm Thomas Klausner. I've been a NetBSD developer for over ten years
now, focusing mostly on pkgsrc and documentation.
I've founded pkgsrc-wip, a project to get more people actively
involved with packaging for pkgsrc, see pkgsrc-wip.sf.net. Everyone
can get an account there and try out packaging for themselves.
I've also found pkgsrc-security, the pkgsrc security team, responsible
for keeping pkgsrc users informed about security problems with
packages; and pkg-bug-handler, the team responsible for managing incoming
problem reports.
NetBSDfr: How did you discover NetBSD ? How long have you been using it ?
wiz: Friends of mine pointed it out to me; I tried it out, and on the
second try (when one of them helped me setting it up ;) ) stuck with
it. That was around 1998/1999.
NetBSDfr: How did you become a NetBSD developer ?
wiz:I started using pkgsrc and found some problems, or new versions of
packages, about which I sent problem reports. After enough of those,
Hubert Feyrer preferred me to commit them myself :)
NetBSDfr:Do you have an idea of the time you spend working
on the NetBSD project daily, weekly, monthly ?
wiz:It varies quite a bit. Sometimes it's half days at a time, sometimes I
don't get to work actively on it for a few weeks. There were periods
when I spent most of my waking hours on it; nowadays I'd guess about
an hour a day, on average.
NetBSDfr:Can you explain us the role of pkgsrc-pmc, and your role in this
organisation ?
wiz:
I'm a member of the pkgsrc-pmc, the Project Management Committee for
pkgsrc. It currently consists of Alistair Crooks, our fearless leader,
Dieter Baron, Amitai Schlair and myself.
The point of the PMC is to decide in technical issues, when consent
cannot be achieved by the pkgsrc developers, and to handle the pkgsrc
freeze.
NetBSDfr:Can you tell us what lead to the decision of creating the
-wip repository ? Do you have any statistics about the number of
package, overall quality.. ?
wiz:There were two main ideas for creating pkgsrc-wip.
One was that there was no place to collaborate on incomplete packages,
e.g. packages where most of the work was done, but some final steps
were missing, or build problems I couldn't fix where I hoped someone
else could continue instead of starting from scratch.
The other one was to get more people actively involved with pkgsrc.
The barrier for becoming a NetBSD developer is quite high, usually,
and if you just want to work on a few packages, you normally won't
reach it. In pkgsrc-wip you can get access by just sending email to me
with your sourceforge username and can get working on packages right
away; also, your work will be immediately and easily available for
other people.
NetBSDfr:What are the criterion that make a package move from -wip to pkgsrc ?
Who makes the decision ?
wiz:Mainly that it works, passes pkglint and a review by an experienced
developer.
Requests for reviews should be sent to the pkgsrc-wip-review mailing
list. There's no formal procedure in place, so the import step happens
when a developer becomes interested enough in the package.
NetBSDfr:In your professional environment, do you work with
NetBSD ?
wiz:Sadly not. I use it as my main desktop at home though.
NetBSDfr:As a conclusion, can you tell us how you do foresee NetBSD's future ?
wiz:I'm not very good with this kind of questions :)
I see NetBSD as a very high quality operating system with great and
motivated developers, and I think that this is very good base for the
future :)

It requires only one command to run the NetBSD test suite on a fresh installation or to check if code changes have caused regressions.
This article explains why and how, and looks into the ATF and Anita tools which make testing so easy everyone should be doing it.