On Sat, 16 Aug 2014 21:31:58 +0200 Raphael Hertzog <hert...@debian.org> wrote:
> 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). There's no need to import the orig. It makes no sense. The packaging lives elsewhere, it develops separately, it is used by multiple upstream branches and it is used for interim builds where there has been no upstream tarball released yet. The timescales are completely separate and there is no benefit in upstream tags colliding with packaging tags. > 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. Then do that on the upstream git, not the packaging git. > > 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. No, not when tags are unrelated and could collide. Standardising git packaging is a pointless and thankless task. Nothing is likely to be gained, just a lot of time wasted on arguing on mailing lists. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
