svn commit: r247035 - head/sys/dev/ixgbe

[Juli Mallett]

On Wed, Feb 20, 2013 at 10:57 AM, Dag-Erling Smørgrav <des at des.no> wrote:
> Jack Vogel <jfvogel at gmail.com> writes:
>> OK, this change must be backed out. This was not run past me, and this
>> is a shared code file, that means its code that we license in both
>> GPL, BSD, and closed source licensing, and thus we CANNOT accept
>> changes without special handling. Further, I do not author this code,
>> its done by another team internally, and I simply accept it as a
>> component.
>
> I think you're confused.  I did not commit this to Intel's code
> repository.  I committed it to FreeBSD's code repository as a precursor
> to a slightly more extensive patch which I intend to commit once I've
> tested it more thoroughly.

Please don't.  Many others have accepted/respected Jack's
maintainership by letting him keep control of the in-tree driver as
much as is possible, particularly outside of ixgbe.c.  I would love to
have committed my code to handle 1G SFPs quite some time ago, but it
makes at least a little sense to me that Jack handles the merges and
testing and whatnot and doesn't need the additional work of
maintaining FreeBSD additions he can't test.  In general, the benefit
of having the Intel drivers updated regularly by someone who has done
extensive testing and who has the backing of Intel has outweighed the
cost of deferring to Intel and Jack about what can go into the
drivers.

If your changes are so compelling, I would have expected them to have
appeared at least on a major public mailing list, rather than
committed at a whim to a driver which has a clear and obvious
maintainer.  If we really do have a lot of wonderful changes that are
stalled by Jack's maintainership, provide a second driver in-tree and
maintain it, which has all the go-faster/better/stronger stripes.

It's not just Jack that unexpected changes to these critical drivers
make things harder for.  There's Luigi, Ryan Stone, John Baldwin,
myself and others, who maintain extensions to the Intel drivers
in-tree and/or privately.

Thanks,
Juli.