|
From: Robert L. <rm...@te...> - 2001-12-07 04:41:22
|
On Thu, 2001-12-06 at 23:19, Tom Rini wrote: > Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a > useable tree. It's always good to try and sync up with > Linus/Marcelo/Alan, but you don't want to be sending every diff to them > either. In the ideal world, kernel.org works for the 95% case for > $(ARCH) and gets updated from the community tree. I completely agree. My point was that ideally there would be no syncing at all. For example, SH could be one of many modules in the official linux CVS. We take care of that. If we touch non-SH code, we hand it to takes care of that. > > Maintaining a divergent tree makes things harder on everyone. It makes > > syncing on our end harder. It causes changes to the kernel with no > > regard to what we are doing (since no one knows). Etc etc ... > > It depends on just how divergent. The sparc tree has some very > different code from time to time than what Linus does, and it either > gets merged or tossed. Same deal for the PPC _devel tree. If you put a > comment (or a msg or two to a relevant list) people know or can figure > it out. I think sparc is an exception because its in vger, which can be said to be its own kernel tree. But I really do think PPC is a good example of how to manage a non-x86 port. PPC64 maybe not (IBM is heavily involved <grin>), but PPC seems pretty well off. > You can't just 'send off a diff', you need to create it, test it a bit, > and hope it doesn't cause any problems. And then that > Linus/Marcelo/Alan doesn't loose it in a flood of other patches/emails. Agreed. We have a current CVS, and we know it works. I rediffed it against 2.4.17-pre5 and it seems fine. So the SH part is trivial. Now, non-SH stuff is a minimum (I think we touch _one_ non-SH-specific item) so that is trivial too. > > Well, CML2 is going in 2.5 in a release or two. Eric Raymond > > specifically says SH is out of sync -- and is the only thing out of sync > > -- at the maintainers request that he do it himself. We won't work in > > 2.5 until this is fixed. > > Working in 2.5 is a non-issue for the moment. 2.5 won't work on x86 for > a while. Hell, I imagine it'll take a while before Linus doesn't drop > other arch patches on the floor. Robert Love |