Andres Salomon wrote: [snip] > > This "Hooray, it compiles!" approach is unlikly to ever produce an > > useful kenrel for architectures not maintained in mainline. > > > > I fail to see why not. How is it we can keep patches in arch-specific > k-i packages, but keeping them in k-s won't work?
As already mentioned on IRC, I misunderstood some parts of your mail an thought the idea was to abolish the kernel-source Package as well. > You mentioned the fact > that mips upstream is essentially a fork of Linus' tree; I suspect this is > the case simply because they wait so long before resynchs, The situation improved significantly for 2.6, however, there's still need to mips-specific patches not in mainline. > and when they > do attempt to synch, they send large patches that Linus rejects. Rather: They send large patches and Linus accepts. :-) > If we're > going to be maintaining and dealing w/ these patches anyway, why not just > feed split out changes to Linus? The easy ones are probably already sent, the hard ones have usually a reason why they shouldn't go upstream as is. The stuff in the middle needs some polishing like updates to more modern kernel interfaces. Of course, I don't oppose to send patches to kernel.org from k-s, but I think it is more efficient to do this between linux-mips.org and kernel.org. > It makes everyone's life easier; for the > next kernel revision, the patch has been merged; mips upstream has less of > a diff between Linus' tree and theirs; and Linus and co. aren't being > bombarded w/ 2 meg patches. 2 MB is the overall diff size, sending it as a single patch would clearly be insane. :-) > As I mentioned above, that's just a goal to work towards. It may work, it > may not. However, a bunch of k-i packages consist mostly of > debian packaging and config files. There's no reason to have those as > separate. For some architectures it clearly makes sense to drop those packages. I just want to keep them for architectures where they are more useful. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
