cvs commit: src/sys/conf files kern.pre.mk src/sys/dev/em LICENSE e1000_80003es2lan.c e1000_80003es2lan.h e1000_82540.c e1000_82541.c e1000_82541.h e1000_82542.c e1000_82543.c e1000_82543.h e1000_82571.c e1000_82571.h e1000_82575.c ...

[David O'Brien]

On Sat, Oct 06, 2007 at 01:36:21AM -0600, Scott Long wrote:
> Erik Trulsson wrote:
>> On Fri, Oct 05, 2007 at 05:05:05PM -0700, Jack Vogel wrote:
>>> On 10/5/07, Erik Trulsson <ertr1013 at student.uu.se> wrote:
>>>> On Fri, Oct 05, 2007 at 10:49:09PM +0000, Jack F Vogel wrote:
..
>>>>>   Log:
>>>>>   MFC of Intel driver version 6.6.6
..
>>>> Am I right in thinking that this code is actually newer than the
>>>> code in -CURRENT (which seems to be version 6.5.3) ?   If this is
>>>> indeed the case, then shouldn't this code have gone into -CURRENT
>>>> first?
>>>
>>> Yes, it is newer, the reason for this is the delta between what
>>> CURRENT has and this is small, and I did not want to impact CURRENT
>>> while its frozen getting ready for release.
..
>>> I would actually have liked to update BOTH CURRENT and STABLE with
>>> this but I was holding off on CURRENT because there are no critical
>>> bug fixes it doesnt have, and its about to be made into a release.
>>
>> As I understand it the policy of FreeBSD is that new stuff *always*
>> should go into -CURRENT first before it is allowed to go into any
>> -STABLE branch.
..
> What do you expect to accomplish by lecturing a vendor who has shown
> very good faith over the years in supporting FreeBSD?  Maybe we should
> tell Intel to piss off since you obviously know how to support their
> hardware much better than they do.

Scott, I think you're being overly harsh.

Erik was not questioning how this vendor and active FreeBSD committer was
supporting their hardware.  It was a question about FreeBSD practices.  I
think it is a fair question - and one that shows how badly our current
situation of having HEAD tree frozen for an overly extended amount of
time is putting a real crimp on our practices.

-- David