[PATCH] rpaphp broken in ameslab

[Paul Mackerras]

linas at austin.ibm.com writes:

> OK.  The short answer for eeh.c is 'all of it'.

OK, that doesn't give me the explanation that would need to go with
the patch when I send it to Andrew.

I want to see a notifier list exported by eeh.c as I proposed in a
previous email before that goes upstream.

> I do have one big concern with tracking patches by email vs.
> tracking patches in bugzilla, and that is the problem of closure.
> I sent four patches yesterday, heard responses for two of them.
> What about the other two? Were they applied? Rejected? Still
> in the queue? Accidenetally ignored & forgotten?    How will
> I know?  In bugzilla, theres a very clear idea of what the

I thought I replied to all 4.  Let me check...

I have replied to the emails with the subjects:

[PATCH] [2.6] PPC64: log firmware errors during boot.
[PATCH] PPC64: lockfix for rtas error log
[PATCH] PPC64: (resend) Janitor signature of rtas_call() routine
[PATCH] PPC64: Janitor log_rtas_error() call arguments

(Yes, the last one I didn't directly reply to, but I rediffed the
patch and sent it to Andrew with a cc to you.)

The trouble with bugzilla is that it doesn't give me the final patch
with explanation, ready to go upstream.

> status is, and there's a 'paper trail' to go with it.
> Its got built-in nagging ... I can say things like 'please
> apply patch 7538, its been ready for months', which works out
> a lot better than 'hey remember that email I send you months
> ago, did you ever get around to it?'

I would much rather you sent me the patch with explanation and said
"please send this upstream".  If I send it upstream I will cc you.  I
will either do that or send you a reply telling you what problems I
see with the patch.  If I don't feel free to re-send at 2-day
intervals. :)

> Problem with un-adorned email is you never know if a thread
> came to a conclusion or not.  But bugzilla has a built-in
> status tracker.. you know when the thread is dead.

You do know when the thread has come to a conclusion, it's when the
patch is in Linus' tree.

Paul.

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/