Date: Sat, 1 Dec 2007 07:38:00 -0800 From: David Southwell <david@vizion2000.net> To: freebsd-ports@freebsd.org Subject: Re: duration of the ports freeze Message-ID: <200712010738.00357.david@vizion2000.net> In-Reply-To: <200712010651.58455.david@vizion2000.net> References: <33640.194.74.82.3.1196149681.squirrel@galain.elvandar.org> <20071201132251.GA20300@soaustin.net> <200712010651.58455.david@vizion2000.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 01 December 2007 06:51:58 David Southwell wrote: > On Saturday 01 December 2007 05:22:51 Mark Linimon wrote: > > 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. > > It seems to me we have a good definition of the problem but, at the risk of > giving offence, I am going to suggest that we have gone about solving it > the wrong way. I am going to propose a solution that some may find > controversial. > > Before I do so let me step outsiide the freebsd environment and ask what > our comments would be if MS$ were to announce that they were about to > release an upgrade to their operating system and until the new upgrade had > been released upgrades to existing applications would be barred. I am sure > we would all agree that that was ridiculous. But that is the result of our > current practice. > > What proportion of freebsd users will immediately upgrade to the new > releases?? Maybe 5% or 10% at the most. Mosty users will stick with their > existing release. This means that 90 - 95% of users are being seriously > inconvenienced by the existing port freeze methos. The question is can we > find an alternative?? > > How about maintaining the port tree as usual during the pre release period. > By default all releases in the tree prior to a selected date should > incorporate a release dependency in their makefile that would NOT include > the pending future release. > > As each port is tested against the new release its release depency would be > changed and upgardes could continue to be added to the tree as normal. > > This would mean the majority are not being inconvenienced by the needs of a > tiny minority to artifically hasten changes to ports to ensure they are > compatible with the new release. > > At the moment the tail is wagging the dog and it is becoming less and less > acceptable that we should continue to operate in way that many may feel is > somewhat quaint but seems IMHO to be increasingly arcane and out of touch > with the needs of most users. > > David Southwell > > Just to add a I should have made in anticipation of what many would see as a major objection to this proposal. If my suggestion is followed I accept release schedules would be adversely impacted. Frankly if that is the price we have to pay then so be it. I know developers who are working on the new releases would like to see them out there, being used as quickly as possible. But I do believe such wishes should be given as much weight as the ports freeze method delivers. IMHO haste to deliver new releases is NOT so important to most users who need the system to be working and reliable and support their desire to keep ports up to date with other systems. A new release of the OS now and again is a bonus but not fundamenta. A new realease is really great but it does not have to happen in a rush or at the price of a majore disruption to the ports updating system. IMHO when all our applications cannot be upgraded for more than two weeks then the cost benefit ratio is impacted by a major shift in perception. The cost element moves from inconvenience to unacceptability and the benefit from "that might be useful in the future" to "I do not know whether I really need this". David Southwell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712010738.00357.david>