On Tue, 2008-07-15 at 12:24 -0400, Dan Williams wrote: > On Tue, 2008-07-15 at 08:15 -0800, Jeff Spaleta wrote: > > On Tue, Jul 15, 2008 at 8:01 AM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > > > Yeah, there is actually a benefit to tarball+patches approach we take > > > right now; and that benefit is that it's extremely easy to see just what > > > we've done to the upstream package, and it's usually really easy to > > > extract those changes and push them upstream. You don't want a > > > mega-diff that includes 20 specific patches. > > > > I know of at least one example currently in our cvs where we went from > > a set of separate small patch files to one encompassing patch file. I > > think it was a diff from git. If we move to more advanced vcs are we > > going to have a harder time keeping patches separated? Or is it just a > > matter of education on how not to reach for the easy to produce mega > > patch shortcut? > > That's the problem here: if we move to git (or any DVCS really), as a > packager you would have to be _much_ more aware of how to use the VCS to > achieve the same separation of patches and upstream source. That is true; and there's definitely a steep learning curve there. I'm not sure the learning curve will always seem incredibly steep - as we figure out the best way of doing this stuff and more people become comfortable with it, I'm sure that it would become just as easy a methodology to pick up as tarball+patches ... which isn't exactly a walk in the park the first time you do it, either, if you think back. > You'd need > to do something like topic branches for each patch and then merge each > topic branch into a "release" branch to ensure that each of the patches > was cleanly separated from the main source. Not at all - "git-rebase -i" allows you to very easily maintain a set of git commits as if they were individual patches. e.g. I use this git tree: http://git.et.redhat.com/?p=linux-2.6-fedora-pvops.git to maintain the set of patches for kernel-xen[1]. The only tricky part right now is that the that stock Fedora kernel isn't maintained in git, so I first import all those patches into git as a single commit. The point is, that if you maintained the kernel patches in git, the latest kernel was based on v2.6.26-rc8 and v2.6.26-rc9 was released you would just do: $> git-rebase v2.6.26-rc9 and any patches that had gone upstream would automatically be dropped, you'd have a nice interface for resolving conflicts etc. If you then wanted to drop, re-order, edit, split up or merge patches you would just do: $> git-rebase -i v2.6.26-rc9 Truly, after doing this for a while, I wouldn't dream of going back to tarball+patches for maintaining a package with a git upstream/mirror. Cheers, Mark. [1] - touch wood, this kernel is going away soon ... at last and forever -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
