[PATCH] rpaphp broken in ameslab

[Greg KH]

On Wed, Jun 30, 2004 at 06:03:06PM -0500, linas at austin.ibm.com wrote:
> On Wed, Jun 30, 2004 at 02:14:14PM -0700, Greg KH wrote:
> > On Wed, Jun 30, 2004 at 03:56:28PM -0500, linas at austin.ibm.com wrote:
> > >
> > > My understanding is that Paul Mackerras and Anton Blanchard are the
> > > designated maintainers of the arch/ppc64 tree.  They are responsible
> > > for sending the patches upstream, getting them into mainline.
> >
> > No, you are responsible for sending those patches to them, in public, to
> > get them, and the community, to accept them and then pass them on.  It's
> > not up to them to do all of the work in picking pieces out of different
> > trees and forwarding them upward.
>
> Look, take this up with the management.

Who's management?  I'm not talking company specific issues here.  I'm
talking about the proper open source kernel development model.  As you
are playing in the sandbox, you need to follow the same rules as all
other developers, otherwise the other members of the sandbox get mad and
start ignoring your nifty sand castles you want them to accept.

{ok, so the analogy broke down at the end there, but I hope my point got
across...}

> I'm stating the facts.
> There's a half-dozen or dozen or so developers here generating
> patches for the ppc64 tree, and *everyone* (with Hollis as a
> clear exception?) has been operating the same way.

That's because Hollis properly understands the Linux kernel development
process :)

> The patches go into the sles9 tree, the ppc64 maintainers have the
> responsibility of accepting or refusing the patches and of syncing the
> trees.

Huh?  If the ppc64 maintainers never know about them, how can that
happen?  If the patches are never posted to a _public_ mailing list, how
can you be sure that the patch is even the correct thing to do?

If you add a usb specific patch to the suse tree, how is the usb
maintainer going to find out about it?  ppc64 should be no different
than any other kernel subsystem.

> > Yes, I remember that.  When is "eventually" going to happen?  next week?
>
> Personally speaking? no, not next week. I've got a backlog of bugs
> to clear out first, and when that queue shrinks to zero, then I'll
> get a chance to do new development.  I was hoping to start
> six months ago; but its been emergency bug-fix season, which seems
> to be winding down.

Ah, but wait for it to start up again with the next distro testing cycle
that doesn't have all of those suse bugs in it...

But that's not relevant here.  I want to know when this hack will be
removed, and done properly, in a arch-independent manner.  If it's not
on the shortlist of things to do, I can't live with it, and will have to
remove it, because that means it will never get fixed :(

thanks,

greg k-h

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