Date: Thu, 8 Jan 2004 10:09:02 +0800 From: "Xin LI" <delphij@frontfree.net> To: "'Craig Rodrigues'" <rodrigc@crodrigues.org> Cc: freebsd-threads@freebsd.org Subject: RE: Release criteria for libkse -> libpthread switch? Message-ID: <20040108020905.E5C675299@ftp.bjpu.edu.cn> In-Reply-To: <20040108012007.GA38122@crodrigues.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-threads@freebsd.org > [mailto:owner-freebsd-threads@freebsd.org] On Behalf Of Craig > Rodrigues > Sent: Thursday, January 08, 2004 9:20 AM > To: Robert Watson > Cc: freebsd-threads@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040108020905.E5C675299>