On Mon, Jul 14, 2008 at 10:07:51AM +0200, Andreas Ericsson wrote: > Arjan van de Ven wrote: > > On Sat, 12 Jul 2008 20:10:51 -0400 > >> Presumably one could replicate this as needed. However, there is the > >> question of whether or not it's needed. Remember that the concept > >> using an upstream tarball as the canonical source version that we > >> represent to the world that we are using is nothing more than a > >> policy decision. Nothing in the GPL or anything else said we had to > >> do that, it was just what we *chose* to do (long, long ago, in a > >> galaxy far, far away). > > > > one thing to keep in mind... as comparison, what you don't want is what > > Ubuntu is doing with their kernel (clone Linus and then just edit the > > source tree); it's just one big nightmare (as you can imagine). Keeping > > upstream source and local patches separate is a clear winner (anyone > > who has worked on the alternative will agree with me). > > Well, if they clone and then edit without using separate branches for > their various edits, then ofcourse it'll be a nightmare to manage. Even then, it becomes a real pain. I did some experiments about a year and a half ago where I kept a git-tree that I committed to in parallel to changes in CVS. The git workflow ended up taking a lot more time. With the CVS workflow, dropping a patch in the middle of a series is trivial. With git, it became a royal pain in the ass when later branches would now need rediffing. Editting a diff directly to fix up offsets for eg, is trivial with the patch-in-cvs approach. It was more painful because at the time we carrying huge patches like Xen, but even without that monstrosity, for a package which contains a lot of come-and-go patches like the kernel, it's really the wrong workflow. Quilt is probably a lot more appropriate than git to be honest for a vendor kernel. Something git wins at hands down is getting changes into a tree. Pulling stuff back out is a complete nightmare. Given our goal is to get as many of our patches upstream asap, having a tool that allows to get lots of change IN doesn't really help. > Not for the casual developer with an itch to scratch. I had 6 full > days of work to spend on fixing the touchpad on my particular laptop > (see bugzilla.redhat.com #448656) so the system actually became usable > again, but since I couldn't duplicate the source-tree from the failing > fedora kernel, I had nothing to diff against, so no way in hell I could > send a patch. You'd really want to be basing any work on the latest cvs anyway, of which there are instructions at https://fedoraproject.org/wiki/Kernel (Substitute devel with F-9 or whatever..) Dave -- http://www.codemonkey.org.uk -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
