qemu-devel
[Top][All Lists]
Advanced

[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
=============================================================================





reply via email to

[Prev in Thread] Current Thread [Next in Thread]