[ I had a drafted reply but lost it on a system crash and its subsequent /tmp cleanse. :( ]
On Mon, 2018-06-18 at 12:51:31 +0100, Ian Jackson wrote: > Guillem Jover writes ("Re: Repository switch over to Salsa?"): > > Hey, so the migration is almost done, I need an account name and ssh > > public keys from both of you. I'll send another mail announcing the > > new setup. > > On a tangent: I recently had cause to `dgit clone dpkg' and I was > disappointed that I didn't get the proper git history. Is there a > reason you are not using `dgit push' ? Yes, there are several reasons. I've made a point to only use dpkg itself (the actual version being released actually) as part of its release process, so that obvious issues can be spotted before it even gets uploaded into the archive. I don't even use debuild, nor any other wrapper. The process involves mainly just a clean schroot and dpkg-buildpackage, in addition to installing the result and rebuilding using that, then comparing the two build artifacts, running lintian and the functional test-suite. After that debsign (which I consider a bug in the process, that should be fixed with the "upcoming" dpkg-sign), and dupload. Using dgit would interfere with all this. Another reason is that it requires to tolerate ugly history, for which I have a very low-tolerance. :) And another one is the implications when it comes to autogenerated files shipped in tarballs. I find all the proposed solutions completely unsatisfying. And this is obviously a matter of opinion, but personally I find them all to be just bad practices. :) When it comes to VCS and packaging workflows, I consider the native case a non-issue. For non-native I think all of them suck, TBH. Even the one I'm using! Where I only store the debian/ packaging bits. But for me that's the one that sucks less. I don't think we have yet found a VCS workflow that is universally good. Regards, Guillem