Date: Sat, 1 Dec 2007 07:22:51 -0600 From: linimon@lonesome.com (Mark Linimon) To: David Southwell <david@vizion2000.net> Cc: freebsd-ports@freebsd.org Subject: Re: duration of the ports freeze Message-ID: <20071201132251.GA20300@soaustin.net> In-Reply-To: <200712010308.43873.david@vizion2000.net> References: <33640.194.74.82.3.1196149681.squirrel@galain.elvandar.org> <20071130214228.GM50167@server.vk2pj.dyndns.org> <4750F55B.9030604@highperformance.net> <200712010308.43873.david@vizion2000.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 01, 2007 at 03:08:43AM -0800, David Southwell wrote: > I must say I am having difficulty understanding the policies applicable > during ports freeze. I had hoped that http://www.freebsd.org/portmgr/qa.html and http://www.freebsd.org/portmgr/implementation.html would have been clear enough on what the policies are -- that was the motivation for writing these documents. > The freeze seems to be of longer duration than originally expected As are most of them. Welcome to the world of software engineering schedules :-) > I would however like to ask, on the basis of what is being learned now, > how could the length freezes be diminished on future occasions? After the 5.3 release, there was a lot of discussion between the ports management and release engineering teams on how to do exactly that. To some extent we're dependent on the state of the source tree; changes that affect the ABI cause us to have to go back and re-do package sets. The release engineers are now much more aware of this impact that they were in the past. However, .0 releases are particularly difficult on this front, since we have to live with any ABI mistakes for several years. Thus, it's worth a delay to avoid having to support a bad or questionable implemenation. Unfortunately, these are often not caught until the prelease starts to get widespread testing outside of the developer community. Another cause is that we're trying to get as many packages buildable and useful for release as we can. This is particularly important for the non-i386 architectures, which do not have as large a user base. Note: this time we waited to start the freeze until nearly the RC1 date -- in the past, we had done it earlier in the beta cycles. There's nothing to be done when RC1 slips, however; we want to have as good a package set entering RC1 as we can get. In the meantime, the number of working packages is probably close to an all-time high numerically (I don't have enough sense of historically to say percentage-wise, although I suspect it's a recent maximum). Folks can help out by trying to install systems just from the packages and letting us know what problems they find. mcl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071201132251.GA20300>