Release criteria for libkse -> libpthread switch?

[Xin LI]

> -----Original Message-----
> From: owner-freebsd-threads at freebsd.org 
> [mailto:owner-freebsd-threads at freebsd.org] On Behalf Of Craig 
> Rodrigues
> Sent: Thursday, January 08, 2004 9:20 AM
> To: Robert Watson
> Cc: freebsd-threads at freebsd.org
> Subject: Re: Release criteria for libkse -> libpthread switch?
> 
> > other than that the issue probably got addressed too late 
> in the 5.2 
> > release process.
> 
> Well 5.2 has branched, and let's assume that it will be 
> released shortly after the appropriate QA and bugfixing.
> Are there any issues that would prevent moving to KSE as the 
> default on -current at this very moment, since 5.2 is on its 
> own branch?

I think this (code freeze) is a common practice in release engineering
process, and, personally, I believe it brings good, with a software
engineer's view.

During the release engineering cycle, it is important to have the code
frozen and we have branched RELENG_5_2, which, theorically, is a "frozen"
branch as of the branching day after a considerable period of code slush.
After the branching point, the main effort of the whole project would focus
on fixing known bugs instead of adding some new features or vastly change
the behavior. By avoiding the feature and behavioral changes, the release
engineer and the rest of the team would have chance to stablize the codebase
on a tight timeline, because what we are trying to avoid during the release
cycle usually brings unexpected concussion and may result in a drastically
prolonged release cycle. You know, it's hard to predicate how much time we
will spend on debugging, especially, when the problem appears when some new
code was added, because it is not very easy to determine which part has
caused the problem, and, as a result, the bug could not be easily tracked
down.

So now you may ask why while we have the RELENG_5_2 branched down from HEAD,
no major functional changes were permitted to hit the tree? IMO this is also
reasonable because by allowing massive changes to HEAD before 5.2-RELEASE
was finally released, we may have problem when backporting fixes from HEAD
to RELENG_5_2. Of course, this may delay the development process for a
little period, but I think that's so important to make a successful release,
which, personally, is believed to be the current focus of the whole project.

I think the release engineering process of FreeBSD is one of what the
project should be proud of. The religious of this process sometimes cause
delay of a upcoming release, but it will make the release valuable for a
user to trust. When we are using a FreeBSD RELEASE, we rarely worry about
stablity, performance, nor compability problems it will cause, you see, many
problems were addressed before the release goes out. For a conservative
user, especially users running critical servers on FreeBSD operating system,
this is more important.

So I would say, let's just wait for the end of the semi-freeze state, after
the 5.2-RELEASE.