On Fri, 18 Nov 2005, Jeff Garzik wrote:
> 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.
At least for our unreleased hardware, we can't. However for fixes that
apply to the base driver, we should be able to keep running track of
issues we find and keep the external devel repository up to date. I'm
going to try submitting mini-patches about once a week, and see if i burn
out.
>> 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.
Okay, lets do that for the next time. AFAIK none of the bugs fixed for
2.6.16 are fatal.
> 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.
okay, thanks
-
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
