[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] bug report + fix: e1000.c in 0.10.5 does not properly e
From: |
Bill Paul |
Subject: |
Re: [Qemu-devel] bug report + fix: e1000.c in 0.10.5 does not properly emulate real hardware |
Date: |
Wed, 29 Jul 2009 11:09:06 -0700 |
User-agent: |
KMail/1.5.3 |
Of all the gin joints in all the towns in all the world, Anthony Liguori had
to walk into mine and say:
> Bill Paul wrote:
> > Let me make sure I understand correctly.
> >
> > You must have my previous e-mail with the patch in front of you, with the
> > attached unified diff. Are you saying that rather than just taking that
> > unidiff, from the e-mail I already sent, you want me to send you exactly
> > the same file, only with a different subject line that starts with
> > [PATCH]?
>
> Yes.
There is this thing called the principle of least astonishment. You just
violated it.
> > I'd like to point out that a) while this may be part of some standardized
> > project etiquette, I've yet to see these required steps clearly spelled
> > out anywhere,
>
> Yes, we're definitely overdue for a SubmittingPatches file to live in
> the tree. I suggested that you follow these steps not due to any sort
> of desire to follow arbitrary procedures but because it guarantees your
> patch will get attention.
It clearly had already gotten attention since you e-mailed me about it right
after I submitted it.
> > and b) why can't you just take the diff I already sent and
> > apply/test/molest/etc it now that you have it?
>
> Well first, it's against 0.10.5 which means there's nothing to apply it
> to. It has to be against our development tree.
I'm sorry, but this argument is based on the faulty assumption that the patch
as I sent it wouldn't apply cleanly to the development version of e1000.c. In
fact, it does. ("But Bill, there are a few lines offset..." Yes. I know. The
resulting patched source is still correct.)
> Second, a system scales
> better when you push work down to the outer most nodes. It's easier for
> to have you resubmit a patch and have everyone follow the same
> procedures than to have me manually extract individual patches from
> random threads, tweak them to apply to git, etc.
Again, I'm sorry, but no. The most efficient thing to do here would have
simply been to save the patch that I had previously sent you and apply it.
There would have been no tweaking required, and it would have taken you less
time to do that than to e-mail me asking me to resend the same patch over
again.
And another thing: I am not an "outer-most node" in a "system." I'm a person
who already has far too many demands on his time, not a script that emits
carefully formatted output designed conform to some strictly-enforced set of
rules that aren't even written down anywhere.
I sent in the patch one more time. If it turns out there's some other tiny
thing wrong with it ("Wait, Bill... you didn't run git exactly the right
way!") then either fix it, or just forget the whole thing. Ok?
-Bill
> Regards,
>
> Anthony Liguori
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu
address@hidden | Wind River Systems
=============================================================================
"I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================