Jesse Brandeburg wrote:
We choose 1) Please merge these changes into upstream for 2.6.16, we
realize we missed the merge window for 2.6.15, but should have said so.
ok
Our position is users who need the new hardware support or new features
now can download our driver tarball from sf.net/projects/e1000.
This position causes extra work, a split test base, and constant
mini-forks whenever e1000 patches come in from the community.
Can Intel be persuaded to do development in the netdev tree? We can
keep stuff in a separate branch until it has adequate testing, then
flush it into the upstream branch periodically. This way everybody's
working on the same codebase, but Intel has time to do testing.
2) I drop these patches, wait for a bug fixes-only rediff+resend from
Intel, and e1000 makes 2.6.15.
If I generate some bug fix only patches for 6.1.16, destined for 2.6.15,
they will conflict with the "upstream" branch. Is that okay?
Not really, since its a unified history. 2.6.15-rc becomes 2.6.16.
It's not a branch.
It sounds like the bug fixes should be applied first, then the rest of
the driver updates.
You requested in another email that I diff against vanilla 2.6.14, but
there are already e1000 changes accepted to 2.6.15 that may fuzz my
vanilla diff. I'm struggling how to deal with that.
Not a hard rule, use common sense [as you are already doing]. Think in
terms of branches. Your e100 microcode changes stood alone, therefore
should be diffed (and applied) against the vanilla upstream tree. For
e1000, it should certainly be on top of anything currently in
2.6.15-rc1-git + netdev-2.6.git#upstream-fixes.
I hope that wasn't too confusing :) In general, diff against vanilla
upstream, unless there are additional dependencies.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
