Yesterday, after the general Python BOF, we had a follow-up git migration BOF. There isn't video yet, but it should appear on http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/
Up until now it's "everybody in the same VCS" and that prevents us from migrating. Relax the svn requirement? Have a default team git repository and start migrating packages progressively? This would probably get too disorganised. This discussion was revisited later, see below, with the conclusion that people are welcome to play with a package or two in each workflow, but shouldn't mass migrate any more, yet, to keep some consistency. git packaging has multiple workflows. An option is to have notes on workflow in README.Source. Again this would be too disorganised, we'd like to have all the packages using the same layout. Perl team use full-source and mr to manage all the repos. Also nice tools for setting up new packages/repositories (dpt) and good documentation about the workflow http://pkg-perl.alioth.debian.org/git.html git-buildpackage supports --merge-with-upstream, which allows for a debian-dir-only repo. paultag is a fan of this, but many other people strongly object to it. An option is to only have the upstream branch, tracking upstream tarballs only, rather than having complete upstream git history. This is probably closer to what we want, as we consume upstream tarballs where possible. It sounds like the best solution is to track full upstream source (one way or another) for >90% of the packages, and debian-source only if necessary, because a repo is huge. Problem with the full history in git: size of checkouts for people that want to keep all the team repos checked out. It is still possible to do a shallow checkout if you really need to optimize for volume. Or we could have separate branches with only the debian dir, generated from the main branch, for people who have everything checked out for QA. Sounds pretty hard to use those to interact with the main repo, though. What about packages without an upstream tarball? If we use pristine-tar for all packages, then we have a consistent approach across the team. svn history, do we keep it? with git-svn, or with the kde git-svn-import, each tag becomes a branch which is a pain. One possible solution is to use git-import-dscs to grab all the Debian history from snapshot.d.o. History can be left for now. There is git-replace, which grafts history into a repo, later. Or do a magic merge to introduce history. - Tag names: * Use the normal pristine-tar upstream/<version> for upstream tags * For debian tags corresponding to uploads: debian/<version> as "debcommit -r" does (please use "git tag -s" and sign your tags) - Branch names: * debian packaging branch names: + sid or experimental -> master + wheezy -> wheezy + wheezy-backports -> wheezy-backports * upstream packaging branch name (only a single branch): + sid or experimental -> upstream * pristine-tar - Workflow: * pristine-tar * tag based orig file ONLY if upstream do not publish tarballs. In this case, generate it, then import it in pristine-tar * Decide later if we use git-buildpackage, git-dpm or gbp-pq, give team members time to try - Schedule: * Prepare the migration from SVN to Git, but we don't do it before the freeze. * Decide if we use git-dpm or gbp-pq on the 6th of December, at which point mass migration can start. * If you want play with a couple of packages before the freeze, do that. Say one with dpm, and one with pq, and report back. == End of minutes == I've done some personal investigation since the BOF, and am preparing some really simple migration scripts, so we can get a feel for what it will look like. My scripts so far (very very simple) git://git.debian.org/users/stefanor/dpmt-migration.git SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559
signature.asc
Description: Digital signature
