The Future of Fedora Package Management and the RPM Philosophy

[Jeffrey C. Ollie]

On Sun, 2007-06-10 at 06:17 +0000, Bojan Smojver wrote:
> Jeffrey C. Ollie <jeff <at> ocjtech.us> writes:
> 
> > Once you know more about source code control you'll understand that
> > having the history that went into a patch (and into the source code that
> > the patch is for) lets you do amazing things with patches, like rebase
> > them so that they apply to new versions of released software.
> 
> Just reading Git crash course for SVN lusers (http://git.or.cz/course/svn.html)
> and they are taking about conflicts during a merge:
> 
> "[...] if any changes conflicted, git merge will report them and let you resolve
> them, updating the rest of the tree already to the result state; you can git
> commit when you resolve the conflicts."
> 
> To me, this reads as if each maintainer still needs to understand the new
> upstream code in order to rework the patches so that they apply. Is that what
> you mean by "rebase"? Fix them by hand so that they actually work?

Let's say that when project foobar released v1.0, their source code
repository looked like this:

      +-1.0
      V
A--B--C

When foobar v1.0 gets packaged up by Fedora, the package maintainer adds
some patches to change some defaults or fix some compiler warnings, and
ends up with something that looks like this:

      +-1.0
      V
A--B--C
       \
        X--Y--Z

Later, project foobar releases v2.0:

      +-1.0    +-2.0
      V        V
A--B--C--D--E--F
       \
        X--Y--Z

"Rebasing" is taking patches X, Y and Z, and computing patches X', Y'
and Z' so that the history looks like this:

      +-1.0    +-2.0
      V        V
A--B--C--D--E--F
                \
                 X'--Y'--Z'

X', Y' and Z' may be the same patches, just with different line numbers,
or maybe sections of the patches are no longer needed since upstream may
have incorporated parts of X, Y, or Z in commits D, E, or F.  Source
code management systems like Git can automate a lot of the work of
rebasing a series of patches, but they can't do everything.  Conflicts
will have to be resolved by hand.  And even once the new patches apply
cleanly, the maintainer will still have to test the patches to make sure
that they still work.

Conflicts happen during the rebasing process when commits D, E, or F
alter the same code as patches X, Y, or Z.  Yes, then the package
maintainer will need to understand the code well enough to resolve the
conflicts manually.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070610/edc90314/attachment.sig>