You should lose the chip from your shoulder if you want assistance. _2_5 was never listed that way, it was an internal tree only.
} I nearly fell into the trap. Just recently, 2_5 was listed as } being where the latest development happens. It certainly looked } that way too, with support for more boards than 2_4 had. } Until just this morning, I was thinking I ought to use 2_5! No-one should have used it and the people telling you that you should have used it shouldn't have done that. Go to www.fsmlabs.com/linuxppcbk.html and you'll find info on how to ftp, rsync and bk the latest Linux/PPC kernels. You'll also find pointers to ftp.kernel.org for the latest patches against the Linus tree. } So now you are saying I should have used the 2_5 tree????? } Wasn't I supposed to know (by psychic methods) that the 2_5 } tree is 'dead' now? The list has announcements about changes in the tree status, discussions about moving the trees, merging them, developing new code and merging with Linus. It's a list for those who want to use those trees in any way - lots of useful information. } I figured that would be a list for automated check-in reports } generated by the BitKeeper software. Get on the list and you won't be caught unaware. The _2_5 tree was never a "for outside use" tree. Others were misinforming people, I know. That was unfortuante but the _2_4_devel tree and the _2_4 trees are both public and will not be "dead ends". All changes that Linus will accept (not a simple job) do find their way to Linus eventually. } So anyway, we now have a 2_4_devel tree to wonder about. } Might somebody suddenly decide to delete this tree too? } Will changes get back to Linus, or is this a dead-end too? Thanks for letting us know how the world works. Much appreciated. } Having separate trees also defeats the purpose of revision control. } One is supposed to use branches (or whatever BitKeeper calls them) } for stable, release, development, etc. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
