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. 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) 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 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) 4. we really do not want patches that stomp on each other 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) 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. Not surprisingly, someone like Andrew Morton that needs to rebase regularly from Linus *and* trace transient patches uses quilt instead of an exploded vcs -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list