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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
