Design and Implementation Techniques

Visible software process
Disciplined practices
- Programming style
- Organization
- Documentation
- Processes
Nontrivial architecture
Merciless decomposition
Support for multiple platforms
Libraries, components, processes
Custom, domain-specific languages and tools
Implementation style
- Agressive use of the C preprocessor
- Object-oriented techniques
- Operator overloading

FreeBSD 5.2 Release Policy

Subject: 5.2 is coming!!
Date: Wed, 7 Jan 2004 23:57:22 -0700 (MST)
From: Scott Long <scottl@FreeBSD.org>
To: developers@FreeBSD.org

All,

We've delayed quite bit while install problems and various show-stopper
bugs got fixed.  I think that it's safe to say that we are getting
pretty close to closing the door on 5.2 now.  There are still a few MFC
requests trickling in, so I wanted to publicize the policy that needs
to be followed for the remainder of the 5.2 cycle.

First, there can be no 'instant MFCs'.  All 5.2 MFC candidates must spend
at least 36 hours in HEAD before going into RELENG_5_2.  It's fine to
contact re@ after committing to HEAD to state your desire to also commit
to RELENG_5_2, but don't expect instant approval.  I encourage the 36
hours to be used for as much review, testing, and verification as
possible.

Unless another show-stopper arises, I intend to tag the tree late
Friday night or early Saturday morning (MST -0700).  In accordance
with the previous paragraph, this means that there are approximately
12 more hours for bug fixes to go in and be 5.2 candidates.  This is
_not_ intended to be a signal for people to start rushing stuff in,
but rather a reminder that we cannot hold the release up for forever.
MFC approval is still at the discretion of the RE team.  After this
cut-off, only show-stoppers will be considered for approval.

While 5.2 will certainly have bugs, I'm happy to hold the release up for
true show-stoppers.  A show-stopper generally is a bug that causes a panic
[crash] during normal and reasonable operation of the OS or prevents the
OS from being installed in a way that is documented, and has no reasonable
work-around.  These bugs must be confirmed by a third party to ensure
that it is a problem that is likely to be reproduced in the user base. It
also includes security vulnerablilities that are published by mainstream
security outlets and have not already been addressed in some fashion.

Thanks a lot!

Scott