[PATCH] rpaphp broken in ameslab

[linas at austin.ibm.com]

On Thu, Jul 01, 2004 at 12:17:11PM +1000, Paul Mackerras wrote:
> 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.

The detailed explanations are in bugzilla.  I'll crawl through the
archives and pull these; but this makes me unhappy :(  I personally
would be happier with a process that requires less make-work; these
patches should have been picked up at the time they were authored,
not post-factum.

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

Its currently implemented as a work queue. Is that acceptable?
To keep gregkh happy, I'll move the work-queue to
drivers/pci/hotplug/rpaphp_eeh.c, will this work?

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

OK, right.  I thought a few had fallen through the cracks.
Again, I question the efficiency of this process, it took
longer than it should to figure out what's up.

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

That's not true. Of course it does.

> > 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".

Yes well, I and others were operating under the assumption that you
were actually monitoring bugzilla, and pulling the patches & explanations
from there, merging and sending them upstream.  Clearly, this did not
occur.  The process broke down.  How will we do better next time?

> > 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.

Its an inefficient, error-prone process.  I can generate more patches
a day than I am able to track by email.  Ergo, patch-tracking is a
bottleneck.

--linas


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