Re: [patch] e1000=y && e1000e=m regression fix


* Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

And this is not really comparable to the libata transition at all,
there's no user-visible changed. [...]

well it was Auke who compared it to the libata transition not me ...

[...] For every distro kernel that just builds both driver it's a
completely seamless transition, and for people who build their own
kernel we should find some Kconfig trickery to make the transition
easier. For example we could just built e1000e when CONFIG_E1000 is
set and spill a warning that starting from 1.1.2009 you will have to
have CONFIG_E1000E set aswell.

firstly, a good deal of our alpha testers use =y drivers. Secondly, your
kind of constructive email is exactly what i wanted to see in the first
place...

i dont really care _how_ this gets solved - i'm not maintaining this
code. What forced me to deal with it was this outright denial of my
problem, the ridiculing and NACK-ing of it and general stonewalling.

I'd have preferred to have sent only my first report. The networking
driver guys on the other hand:

1) forced me to send a full bugreport about something that i described
adequately in my very first mail already, and which they should have
immediately recognized, based on the trouble they had with Linus. (i
wasnt aware of that back when i made my report)

2) repeatedly denied that there is any problem. Claimed that "this is a
careful migration balance we decided" and other babbling.

3) forced me to write a patch for code they are supposed to be
maintaining to actually get things moving.

4) moved the regression bugzilla entry to REJECTED+INVALID without
actually resolving the bug and forced me to write several comments
there too. (See http://bugzilla.kernel.org/show_bug.cgi?id=10427)

5) forced me to write 20 mails with still no clear resolution yet at
this point.

it's insane and i'm really curious what kind of language you'd use in
your replies if i ever forced you through such an excercise in arch/x86
or the scheduler ;-)

and no, it wasnt a case of miscommunication. My bug was i think
well-understood in the very first mailings already, but it was
discounted as unimportant and resolution was delayed all the way up
until this point. That shows fundamental insensitivity to bug reporters
which is more worrisome than the bug itself (the bug is fairly minor and
i never claimed otherwise).

Hours of my time wasted on something that should have been a 2 minutes
matter - and yes, as i go through these chores i do get increasingly
annoyed about it, and rightfully so. I cannot just let this happen
silently, way too much crap like this gets pulled off. If the networking
driver guys are pulling off a show like that with a fellow kernel
developer how do they manage to deal with plain users (who, in
comparison, are in essence defense-less against rejections from
maintainers)?

and yes, moving those IDs over into e1000e in v2.6.26 might work out
fine in the end, if the migration is all totally problem free up to that
point. We simply cannot make that determination right now. What exactly
is so hard to understand about the concept of not degrading the quality
of an existing, rather well-working driver?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • MS Word scroll up issue: lines repeat
    ... When scrolling ... hungry and its your video driver". ... like this problem to be correctly submitted as a bug to MS and fixed. ... or provide a way for me to make a bug report? ...
    (microsoft.public.office.misc)
  • Re: sk98lin for 2.6.23-rc1
    ... When did you report this bug the first time? ... The removal of old sk98lin driver caused some ... usage to only fiber systems. ...
    (Linux-Kernel)
  • RE: MS Word scroll up issue: lines repeat
    ... Windows updates KB954464 and KB943983 ... hungry and its your video driver". ... like this problem to be correctly submitted as a bug to MS and fixed. ... or provide a way for me to make a bug report? ...
    (microsoft.public.office.misc)
  • Re: COM port goes to sleep and doesnt wake up
    ... It *is* a specific driver; it just happens to be the easiest one for the PPC ... manufacturers to use. ... You have to report it to the device makers. ... > Even if the bug is in ALL devices running PocketPC (as was suggested by ...
    (microsoft.public.dotnet.framework.compactframework)
  • cvs-src summary for May 31 - June 7
    ... You can get old summaries, and an HTML version of this one, at ... driver for Intel Ethernet cards, then the ndis driver, for emulation of ... Maxime Henrion changed the fxp driver to use the device sysctl tree, ... This bug is covered by `FreeBSD-SA-04:12.jailroute`_, ...
    (freebsd-current)