Re: DebConf14 svn-git migration BOF notes
On Aug 30, 2014, at 03:00 PM, Steve Langasek wrote: Relatively few at this point, but there is a session here at DebConf14 this evening that will be streamed and might be worth following: https://summit.debconf.org/debconf14/meeting/75/dgit-treat-the-archive-as-a-git-remote/ Darn, I was traveling and missed the live stream. I'll keep an eye out for the session to show up on the video site. -Barry signature.asc Description: PGP signature
Re: DebConf14 svn-git migration BOF notes
On Wed, Aug 27, 2014 at 04:24:29AM +0200, Stefano Rivera wrote: - 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) You can use debcommit --sign-tags -r to sign your tags (or even better, set DEBCOMMIT_SIGN_TAGS=yes in ~/.devscripts). Cheers, Javi signature.asc Description: Digital signature
Re: DebConf14 svn-git migration BOF notes
Thanks for sending out the minutes Stefano. On Aug 27, 2014, at 04:24 AM, Stefano Rivera wrote: - 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) Note that git-dpm uses different tag names than gbp, e.g.: [~/projects/debian/lazr/smtptest:1017]% git tag debian-2.0.1-1 debian-2.0.2-1 patched-2.0.1-1 patched-2.0.2-1 upstream-2.0.1 upstream-2.0.2 So we'll have to adopt the tag names for whichever regime we choose. Cheers, -Barry signature.asc Description: PGP signature
Re: DebConf14 svn-git migration BOF notes
On Aug 30, 2014, at 11:02 AM, Javi Merino wrote: You can use debcommit --sign-tags -r to sign your tags (or even better, set DEBCOMMIT_SIGN_TAGS=yes in ~/.devscripts). You can also put this in your ~/.gbp.conf file: [DEFAULT] pristine-tar = True [git-buildpackage] sign-tags = True ignore-new = True export-dir = ../build-area/ -Barry signature.asc Description: PGP signature
Re: DebConf14 svn-git migration BOF notes
Several people mentioned dgit as something we should look at. I like the idea of dgit as a udd-killer since I really like UDD in Ubuntu. Does anybody have any experience with dgit for package maintenance? -Barry signature.asc Description: PGP signature
Re: DebConf14 svn-git migration BOF notes
On Sat, Aug 30, 2014 at 01:29:34PM -0700, Barry Warsaw wrote: Several people mentioned dgit as something we should look at. I like the idea of dgit as a udd-killer since I really like UDD in Ubuntu. Does anybody have any experience with dgit for package maintenance? Relatively few at this point, but there is a session here at DebConf14 this evening that will be streamed and might be worth following: https://summit.debconf.org/debconf14/meeting/75/dgit-treat-the-archive-as-a-git-remote/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: DebConf14 svn-git migration BOF notes
* Stuart Prescott stu...@debian.org [2014-08-27 13:29:39 +1000]: Hi! 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. BTW svn-all-fast-export is the package that contains the kde git-svn-import tool -- it does rather have a naming crisis. svn-all-fast-export accepts a mapping that takes an svn tag and turns it into a git tag. It also takes svn branches and map them into git branches. Further details are at: https://wiki.debian.org/PackagingWithGit/Svn- buildpackageConversion#Importing_using_svn-all-fast-export and if you `debcheckout translate-toolkit` you will find a git repo that looks like a git repo for git-buildpackage should, even if some of the older commit messages are prefixed by '[svn-upgrade]'. The mapping rules on that wiki page are the ones I used for translate-toolkit and most packages would have the same rules with only s/mypackage/otherpackage/. Hey gang, I did a migration using svn-all-fast-export a (long) while back. The results are on http://anonscm.debian.org/cgit/users/olasd/dpmt/. I've been very annoyed with the svn tag - git branch mapping, and I haven't had time to script fixing those up. I also have no idea how to graft the upstream history there if we want sourceful repos (but I guess we can just not care about it). The stuff I used is in alioth:/home/users/olasd/dpmt_migration and should be world-readable. If you're so inclined, I could probably walk you through it, but considering that that was done 9 months ago, it is probably better to start from scratch anyway. Cheers, -- Nicolas Dandrimont BOFH excuse #122: because Bill Gates is a Jehovah's witness and so nothing can work on St. Swithin's day. signature.asc Description: Digital signature
Re: DebConf14 svn-git migration BOF notes
On Wed, 27 Aug 2014, Stuart Prescott wrote: 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 is there any reason to use a loop around git-import-dsc rather than git- import-dscs --debsnap here? I haven't looked at stefano's script but git-import-dscs will import all source packages in a single linear history (importing the packages by increasing version) and that isn't representative of the true history. For python-django, I imported all the normal versions in the debian/sid branch but manually imported the +deb7uX in a debian/wheezy branch, the +squeezeX in a debian/squeeze branch, etc. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827085224.gd23...@x230-buxy.home.ouaza.com
DebConf14 svn-git migration BOF notes
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
Re: DebConf14 svn-git migration BOF notes
Hi! 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. BTW svn-all-fast-export is the package that contains the kde git-svn-import tool -- it does rather have a naming crisis. svn-all-fast-export accepts a mapping that takes an svn tag and turns it into a git tag. It also takes svn branches and map them into git branches. Further details are at: https://wiki.debian.org/PackagingWithGit/Svn- buildpackageConversion#Importing_using_svn-all-fast-export and if you `debcheckout translate-toolkit` you will find a git repo that looks like a git repo for git-buildpackage should, even if some of the older commit messages are prefixed by '[svn-upgrade]'. The mapping rules on that wiki page are the ones I used for translate-toolkit and most packages would have the same rules with only s/mypackage/otherpackage/. - Workflow: * pristine-tar While I currently use pristine-tar on all my packages and I think it's a reasonably important part of our infrastructure at this stage, I'd urge a little caution here given that it is orphaned both in Debian and upstream. http://bugs.debian.org/737871 [...] 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 is there any reason to use a loop around git-import-dsc rather than git- import-dscs --debsnap here? thanks for reporting back from the BoF for us! cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ltjjb5$4i3$1...@ger.gmane.org
