Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: >> Once there is a public tree with 2.6.20-rc1 + ipipe + -rc2, you cannot >> simply turn that tree into 2.6.20-rc1 + -rc2 + ipipe. The order of >> patches is practically frozen once published. In your private tree you >> are, of course, free to do this and then extract some patch to post >> upstream. > > I'm not sure if it really makes sense to maintain this as a git > repository - that would be OK if we wanted to provide a pre-patched > tree to the public (which might be a good thing to have, btw.).
This is one of my motivations to push git forward. Having 2.6.20-rcX+ipipe already available for download and testing may help to follow the kernel development on the bleeding edge more closely. The other aspect is that when you merge the kernel patches into a working ipipe tree and you get a conflict, you also directly obtain information about what change caused it and maybe what the background of that patch was. That's at least my theory which still needs to be proven in practice. > > As long as we're basicly trying to manage the patches in a way that > integrates well with git we should do exactly that: manage the > patches under git, i. e. use stgit (see http://www.procode.org/stgit/). I heard about it before, but I still have to take a closer look. Does this generate also some kind of publishable git tree with history for the managed patches? One problem with a stack might be that we loose information about ipipe changes themselves. My idea is that some modification to the ipipe core stored as commit in the reference tree could directly be pulled by other arch maintainers. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
