hubertf's NetBSD Blog
Send interesting links to hubert at feyrer dot de!
 
[20100908] New core team policies: automated testing and peer review
Antti Kantee has recently joined the NetBSD core team, here is a first core announcement sent out him about two new policies:

  1. ``new tests must be written using the Automated Testing Framework (ATF)
  2. core will no longer ok changes without prior public discussion
Extended versions:

1) NetBSD has always been known for its high quality. To take quality to the ultimate level, we are actively pushing for automated testing with regularly run tests and uniform test reports. To this end, we now require that all new tests are written using the ATF tool. All exceptions for tests committed to the old src/regress framework must be ok'd by core prior to commit.

You can find information about ATF from http://www.NetBSD.org/~jmmv/atf/ and help on writing tests at http://wiki.NetBSD.org/tutorials/atf/

Please test responsibly.

2) In the past the core team has given an ok/no decision for changes directly upon private request. To make NetBSD's review process more transparent for developers and non-developers alike, core will no longer bless a change without peer review on a public technical list. The only exceptions are cases requiring confidentiality, such as security vulnerabilities.

It is still desirable to inform core about long-term projects you are working on. This way they can be part of the roadmap for NetBSD. Be sure to state if you wish your project to remain confidential until further notice.

Developers please note that large changes such as adding new packages to src/external and sweeping kernel changes still require both peer review and core approval. Contact core@ if you are unsure about the nature of your change. ''

I regard both moves as excellent. For those non-developers out there that want to participate, #1 may be an interesting thing for projects: Pick a part of the system, and write regression tests to make sure things work. Guidelines may be found e.g. in the Single Unix Specification (SUS).

[Tags: , ]


Disclaimer: All opinion expressed here is purely my own. No responsibility is taken for anything.

Access count: 35111049
Copyright (c) Hubert Feyrer