Date: Sat, 7 Jan 2006 20:12:02 +0100 From: Tobias Roth <roth@iam.unibe.ch> To: Doug Barton <dougb@FreeBSD.org> Cc: ports@FreeBSD.org Subject: Re: New rc.d code merge timing (Was: Re: Portupgrade confused about editors/emacs) Message-ID: <20060107191202.GA18881@droopy.unibe.ch> In-Reply-To: <43BF7430.80509@FreeBSD.org> References: <834B3A07-EC76-4645-8E1B-7ABEA4EC999A@submonkey.net> <43BE57E9.9060507@rogers.com> <43BE61C9.9060502@ebs.gr> <43BE63E7.4060209@rogers.com> <20060106124508.GB14967@droopy.unibe.ch> <20060106125428.GC79296@pcwin002.win.tue.nl> <20060106131231.GC14967@droopy.unibe.ch> <43BF7430.80509@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 06, 2006 at 11:56:32PM -0800, Doug Barton wrote: > > Your point here has a lot of merit, and I think it's worth my explaining > the reasoning for doing this the way I did. The primary motivating factor > was the upcoming freeze for the RELENG_6 branch on January 30. We knew that > the code in the base was sound, and did what it was supposed to do. We also > knew that there were going to be some ports that needed fixing. The problem > is that we have a chicken and egg issue here. A lot of testing was done on > the boot scripts of a lot of ports, but not only were errors discovered in > boot scripts that seemed perfectly valid, but many of the problems we're > seeing now are related to ordering issues. This in turn depends on what > combination of ports that the user has installed. All the testing in the > world would not have uncovered every possible way for this to break, > although it might have reduced some of the pain. Ultimately, this is going > to be part of the process of enabling this functionality any way you slice > it. > > It's also worth noting, although I've posted these stats before, that there > are roughly 650 ports that install boot scripts. Of these, 350 have been > converted to new style rc.d, the others have not. The 300 that have not > been converted are not affected by this change. Of the 350 that have been > converted, very few have exhibited problems. That's not to say that the > problems we've seen aren't important, and obviously they need to be fixed. > However this is a pretty good track record overall. > > At the end of the day, and after extensive discussion with the various > stakeholders, I made the decision to MFC sooner than later in order to get > things as cleaned up as possible before the freeze. I still think that's > the right decision, but I acknowledge that reasonable minds could differ on > this topic. I can understand your position. Yes, I personally would have done it differently but I also accept that there are good reasons behind a quick MFC in this case. And since most people (including me) will not run -STABLE on their production boxes, it may be not that much of a problem if some ports startup scripts are broken for a while. Hopefully, all problems have been uncovered once 6.1 will be shipped. thanks, t.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060107191202.GA18881>