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. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
