On Aug 10, 2016, at 11:53 AM, Nikolaus Rath wrote: >I think the only way to make this less painful is to get rid of the idea >of managing patches in a VCS and use something like gitpkg. This has the >drawback source package is now *generated* from the Git repository >(i.e., you can't do git clone + debuild), but it makes maintaining the >Git repository much less painful. Judging from all the attempts I've >seen so far, trying to put patches (i.e., the output of a VCS) under >version-control is just a doomed endeavor. > >I don't believe that switching from git-dpm to git-buildpackage is going >to make things easier, it'll just be trading one set of problems for >another.
Two thoughts: * We probably need to do some actual experimentation on actual packages, so we should plan for allowing that on a limited basis, with the caveat that once a new workflow is chosen, we'll make all team packages consistent again. * With git-dpm we *had* to enforce the tool choice because git-dpm's artifacts had to be preserved. If we ditch git-dpm, is that still the case? IOW, if you choose to use gbp-pq, am I forced to do so when I modify the same repo? Or if you choose to use PoQ (plain 'ol quilt), will that affect how others can co-maintain the package in git? We only need to mandate workflows and conventions where the effects and artifacts are visible after a package is updated. Think of it like the choice of editor - no one cares whether you use vim, emacs, gedit, or whatever to modify the files, because its effects are only local to you (for the most part). Cheers, -Barry
