[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Repository switch over to Salsa?

[ 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.


Reply to: