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
Attachment:
signature.asc
Description: Digital signature