On Sat, 2008-07-12 at 17:49 -0700, 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). > If those upstream sources are a tarbal, or a tagged commit... is a lot > less relevant. 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. One problem working directly on exploded source trees is that you as a developer have to be much more disciplined to make small, targeted commits that are easily able to go upstream, otherwise you do end up with a huge diffmess that you simply can't upstream easily. And that's where we should always be working: upstream. Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
