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 ...
obrien at freebsd.org
Mon Oct 8 09:18:44 PDT 2007
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:
>>>>> 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
>>> 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.
More information about the cvs-all