On Tue, Sep 6, 2011 at 7:27 PM, Jef Spaleta <jspaleta@xxxxxxxxx> wrote: > As more projects become git based over time, the preferred form for code > development might actually be a bisectable git checkout +100 -- some of the git primitives seem to be here to stay - a hash identifying a commit or tree as the key identity, plus repo url, and optionally a branchname. You can see those 3 with minimal variation across DSCMs. Perhaps fedpkg could grow some tentacles to make it easy to replace the source tarball with a reference to a commit hash, and perhaps to point to a 2nd repo/branchname/hash where the "as patched in this fedora rpm" branch is available. That commit being a direct descendant of the "upstream commit". If you define the config stanzas and internal API around those 2 triplets, I think you can start with git and then extend to the relevant DSCMs . This would make rebasing patchsets (dropping patches as upstream merges or nixes them) -much- easier. It would require a 2nd set of git repos, however, where fedora has full clones of upstream's git repo with the fedora-specific branches. Upstream projects may or may not welcome the fedora braches in their repo... Fedora may want to keep more direct control over them re commit access and direct manipulation (branch renames, etc). Maybe that can be rolled into what's tracked in pkgs.fp.org, but the size difference is... um... :-) m -- martin.langhoff@xxxxxxxxx martin@xxxxxxxxxx -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
