Hi, On Sat, 16 Aug 2014, Philip Muskovac wrote: > I'm writing this from a Kubuntu POV which should be close to > debian-qt-kde as we have a pretty close workflow (one of the reasons why > we're talking about moving our branches to their repositories) as we > also only keep the debian/ dir in the VCS.
Thanks for your feedback! A couple of comments though: > a) Consistent VCS based packaging workflow > While upstream has switched most of their repositories to git, > there's a couple (artwork related) repositories that are kept in > SVN, so if we would use a git-based workflow with source and > packaging together, we would have to manage different workflows > for specific packages within the same release which is something I > would prefer not to do. In both cases upstream releases tarballs, no? So that could be the layer that offers the consistency that you're looking for (with the help of gbp import-orig). > b) Repository size It's clear that having the upstream sources takes a lot of space and it takes a while if you download everything at once. But in my experience it has never been a problem. I must test build every package that I modify so I need the sources anyway. And there's a lot of value in the history. I often do "git log -p setup.py" or "git log -p Build.PL" to discover new dependencies introduced by a new upstream release. FWIW my Kali work directory contains 200 repositories (and "linux" is one of them) and takes about 6 Gb. Hardly a problem with the size of current harddisk. We use gbp import-orig and pristine-tar. > c) Upstream tag management > The KDE release team currently publishes tarballs with checksums > and git/svn revisions to packagers before the actual release for > build testing and early Q/A. So when we build the packages, there > is no git tag yet that we could use to generate a tarball > ourselves, we would have to parse the tarball list for the commit > hash that was used to generate the tarball and base our packaging > on that - or wait for the tags and loose the chance to give the > release team pre-release feedback. Again the upstream tarballs are sufficient if you use a workflow based on gbp import-orig. > Aside from the different workflow, I do like the tagging proposal with > vendor/version as that did not yet come up in my discussion with the > debian-qt-kde folks. I wanted to have this discussion for a while, but when I learned of this shared repository plan I decided to go forward thinking that it could be useful in this specific case... Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140816193158.gj13...@x230-buxy.home.ouaza.com
