IBM 440GX, Ocotea...

[Jaap-Jan Boor]

Paul,

Much thanks for your explanation, it clarifies a lot.

Jaap-Jan

On Thu, 25 Mar 2004, Paul Mackerras wrote:

>
> Jaap-Jan Boor writes:
>
> > In addition to this nice tree discussion, I've a question:
> > from what 'official ppc' tree do patches eventually get into the
> > official linux kernel tree(s) at kernel.org?
> > only linuxppc-2.4? Or all?
>
> Well, the thing to understand is that there is no automatic,
> effortless way that code goes into the kernel.org trees.  Every change
> that goes in involves somebody putting together a patch against the
> current state of the official kernel.org trees, together with a
> description of what is being changed and why it is being changed, and
> sending that to Marcelo Tosatti, Andrew Morton or Linus Torvalds.
>
> BitKeeper can help to some extent with this, mainly by providing a way
> for us to send Marcelo/Andrew/Linus a bunch of changes in one go.  It
> doesn't, however, provide any automatic way for changes to get from
> the linuxppc-2.4 or linuxppc-2.5 trees into their trees.  The reason
> is that with BK, if you pull the changes from one tree into another
> tree, you have to take all the changes in the first tree that aren't
> in the second.  You can't pick and choose which changesets get
> transferred.  Therefore, we don't ask Marcelo/Andrew/Linus to pull
> from linuxppc-2.[45] into their trees.  There is too much stuff in
> there that isn't ready, or that I don't agree with, or that I just
> don't understand.
>
> I have taken on the role of ppc32 maintainer, part of which involves
> sending changes to Marcelo/Andrew/Linus.  However, doing that involves
> work on my part to identify which changes in linuxppc-2.[45] are ready
> to send, which changes logically go together, and I have to be able to
> explain the change.
>
> When it comes to things like the 8xx/82xx/85xx support, I rely on the
> maintainers for that area -- Tom Rini and Dan Malek -- to do that work
> of identifying sets of related changes that are suitable for inclusion
> in the official trees, and packaging them up with an explanation so
> that they can be sent upstream.  (That can be done either with patches
> or BK changesets; the amount of work required is pretty much the same
> either way.)
>
> Similarly, for the boot code I look to Tom and for the powermac
> support I look to Ben Herrenschmidt.  For the 4xx stuff there isn't
> really a maintainer at the moment, unfortunately, except that Matt
> Porter is looking after the 44x boards.  I look after the classic
> PowerPC core support -- exception handling, memory management, etc.,
> and to some extent the 4xx core support, and the CHRP port.
>
> What this boils down to is that for changes in these areas I expect
> the maintainers for those areas to be packaging up the changes with
> explanations, ready to go upstream.  Anyone is of course welcome to
> put together a patch + explanation and propose that it go upstream.
> In such cases I would ask the maintainer for that area for his
> opinion, or if there isn't a maintainer, I would ask the submitter if
> they will commit to maintaining that area of the code.  If they won't,
> I would tend to drop the patch unless it is a simple, obviously
> correct bugfix.
>
> One problem we have at present is that there are a number of board
> ports which don't appear to have a maintainer.  Sometimes there are
> people using those ports but noone taking responsibility for updating
> it and keeping it working as things change elsewhere in the kernel.
> Having a maintainer is a prerequisite for the board port to be sent
> upstream.
>
> I hope this clarifies things.  If you want the kernel.org trees to
> support your platform, then I suggest you put together the changes you
> want to see as patches and send them to me and the maintainer for the
> subarea.  Make sure that the patch comes with a good explanation of
> the change, and if you think the patch should go upstream, say so.  If
> possible make sure that the patch isn't too large.  If it is large,
> see if you can split it up into smaller patches, each of which
> contains a logically related set of changes.
>
> Regards,
> Paul.
>
>

--
J.G.J. Boor			  Anton Philipsweg 1
Software Engineer		  1223 KZ Hilversum
AimSys bv              		  tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum   mailto:jjboor at aimsys.nl


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