New rc.d code merge timing (Was: Re: Portupgrade confused about editors/emacs)

[Doug Barton]

Tobias Roth wrote:

> This (at least from my part) was not critique on the responsivenes,
> but on the time and nature of the MFC. I claim it was not long enough in
> CURRENT to be MFCed. And since it was known beforehand that the change
> will possibly affect many port maintainers who will then have to adapt
> their ports, the time of the MFC was was badly chosen. If I commit or
> MFC something that I can fix myself during holiday season, that's ok.
> But if I commit something that needs the help of many people, in case it
> breaks, the holiday season is a bad moment to commit.

Tobias,

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.

Regards,

Doug

-- 

     This .signature sanitized for your protection