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

[Andreas Ericsson]

Dan Williams wrote:
> 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,

Easier than, oh, say "git log -p --reverse fedora..upstream" ?

> 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.
> 

Who's talking about mega-diffs? You can get each diff individually with
any sane scm (and with quite a few of the insane ones as well).

> 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.
> 

That's really no difference at all to what needs to be done now. Each
patch has to be kept and generated separately. Using a tool for it only
means you have a much easier way of moving that patch-set around and
automagically finding already applied patches.

> And that's where we should always be working: upstream.
> 

So work with the tools they have then. I manage a few projects in git,
and I'd much prefer to get patches sent to me via the git tools than
someone using diff on two exploded source-trees. I'd *love* to get
pull-requests, since I won't have to bring any sourcecode or patch
outside the scm at all that way.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231