Heads-up: brand new RPM version about to hit rawhide

[Dave Jones]

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