Heads-up: brand new RPM version about to hit rawhide
Dave Jones
davej at redhat.com
Wed Jul 16 18:33:59 UTC 2008
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
More information about the fedora-devel-list
mailing list