RFR: GIT Package VCS

[Toshio Kuratomi]

On Thu, 2007-06-07 at 23:04 +0200, Nicolas Mailhot wrote:
> Le jeudi 07 juin 2007 à 22:25 +0200, Nicolas Mailhot a écrit :
> 
> > > Disconnected mode is a killer argument for changing from cvs-dist to
> > > DRCS-dist.  It doesn't address the reasons that exploded trees are good.
> > 
> > Well you've convinced me pretty well they're *not* good in a fedora
> > packaging context.
> 
> To expand a little more : the primary form of our "sources" is published
> upstream archive + fedora patches, because fedora users that audit code
> will audit these bits separately. Clear separation of Fedora changes is
> more important than seamless upstream integration.
> 
I agree with this.  Where we disagree is whether the implementation of
exploded trees will interfere with this or not.

> 1. "rebasing" should always start from a published archive, not an
> upstream vcs tag/label (very often upstream tags something and releases
> an archive that saw manual tweaks)
> 
I agree with this.  I don't support using upstream's tags instead of a
published archive.  We should always import upstream's archive into the
DRCS.  It's a vendor branch.  When upstream is using the same DRCS as we
are using we can use their tree in addition to the vendor branch as a
way to merge fixes for their current head that are easier for them to
add to their tree but the branch that we use to create the packages
should always stem from the vendor branch.

> 2. we don't really care what happened between two upstream releases,
> that's best traced in the upstream vcs, a giant changeset between them
> is more pertinent  at the fedora level than all the upstream change
> history
> 
We do when we're backporting a specific fix from upstream's development
tree.

> 3. we don't really care what happened on the packager system either,
> just what was pushed as a build (or attempted-to-built package)
> 
I disagree with this one quite a bit.  1) For the reviewer/auditor: When
a patch changes, don't you want to see what change was made?  The
current output from cvs is quite garbled (it's a diff of a diff.)  It
would be much better to see this as changes to the tree with the
previous patch applied and the tree with the current patch applies.  2)
The packager is developing code.  It may only be a patch against
upstream but that doesn't mean the good practices associated with using
a VCS to checkpoint your changes goes away.

> 4. we really do not want patches that stomp on each other
> 
Actually, we do.  One example is that I sometimes have to make several
fixes to configure.ac andMakefile.am files to build a package.  These
changes are often separate changes that should go to upstream in
discrete patches.  Therefore I generate several patches for this which
each touch these files.  A DRCS makes management of these patchsets
easier.

> 5. it would be nice to distinguish between patches intended to be pushed
> upstream and just-for-fedora patches. *if* we decide to trace this info
> however, it should be traced in the spec file too one way or another (ne
> patch-for-upstream element, patch naming conventions, annotations,
> whatever)
> 
Yes.  And exploded trees don't interfere with this.

> Given all those points, non-exploded VCS has the clear advantage of
> forcing the packager to separate upstream and packaging work instead of
> blurring the boundaries. An exploded export of source+patches for
> upstream is possible, but killing the source+patches stage at the import
> level seems dangerous.
> 
Could you explain the import level statement?  I think I've dealt with
the rest of your concerns above.

> Not surprisingly, someone like Andrew Morton that needs to rebase
> regularly from Linus *and* trace transient patches uses quilt instead of
> an exploded vcs

This is what I'm talking about.  The Ubuntu page outlines how to combine
a DRCS with quilt-like functionality.  That's why I say that it's good
reading.  Merely using an exploded tree without incorporating features
found in quilt is not a good idea.  (How to map quilt features into the
DRCS could be debated but the fact that it has to be done somehow is a
no-brainer to me.)

-Toshio
-------------- 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/20070607/f53cc02a/attachment.sig>