On Saturday 16 August 2014 17:09:54 Raphael Hertzog wrote: > On Sat, 16 Aug 2014, Scott Kitterman wrote: > > Silly or not in your opinion, the Qt-KDE team repositories are set up this way. > > Sorry, I wasn't aware of that and didn't want to imply anything on people > using such a scheme. > > Still it would be interesting to know why the team made this choice and > what tools they are using to make this work. Anyone has pointers or can > explain us the choices made? 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. 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. b) Repository size Cloning the upstream kdelibs repository is currently a ~158MiB download, and while that might be one of the largest repositories, a KDE SC release consists of ~170 tarballs so even leaving the SVN managed ones aside you have to download *a lot*. It is a lot easier to work with a couple MiB large packaging repositories that only manage the debian/ folder. (Add KDE Frameworks 5 and Plasma5 and you've far surpassed the 200 package mark) 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. I might've missed something else, but those are some of our reasons for not managing the source ourselves. Both bzr builddeb and git buildpackage can download a tarball during the package build in case the upstream source isn't already there (I usually rely on watch files in the packages and deb-src entries in my apt configuration for that) 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. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part.