Re: The Difference between debcheckout and dgit and what they try to accomplish
Hi,
Let me try to answer multiple mails as one:
On Mon, Jun 17, 2019 at 07:44:39AM +0200, Andreas Tille wrote:
> In other words: If vcs-git would be uniform would this be more
> attractive to you?
Maybe. Uniformity certainly is an important property to me. Having to
figure out different workflows is simply too much when the average
budget per patch is supposed to be less than a quarter of an hour.
Uniformity is not sufficient though. QA-tooling tests what is uploaded
to unstable. As long as it tests unstable and not vcs-git master, I want
that unstable tree and not the vcs-git master.
On Mon, Jun 17, 2019 at 11:27:07AM +0200, IOhannes m zmölnig (Debian/GNU) wrote:
> out of curiosity (and because i usually quite enjoy your patches): do
> you do use dgit in *your* workflow?
Presently, no. I attempted using it, but I feel that the extra
complexity did not help my use case. dgit solves a difficult problem and
that comes at a cost. Verification of source integrity is much more
difficult to understand with dgit (and it presently seems to have a
trust root in the ca business). The integrity checking performed by
apt-get source on the other hand is quite easily explained (if you
assume gpgv). Then, I'm not interested in commits that are not yet
uploaded. I want to reproduce the exact failure that QA saw. I
occasionally look into history of packages to figure something out. For
this case, dgit is not useful due to its low adoption and being young.
On the other hand, debian/changelog often suffices here.
So it's not like dgit would be bad. It just seems to solve a different
problem than the one I have.
On Mon, Jun 17, 2019 at 11:47:38AM +0100, Sean Whitton wrote:
> It would seem, then, that what we want is merge requests against our
> interchange format: the source packages that actually get uploaded. Or,
Yes. And as much as people may dislike it, a working way presently is
sending a .debdiff to the bts. We require maintainers to receive such
mail. (When the maintainer address bounces, we file rc bugs.) We require
maintainers to interoperate with the bts. Presently, you cannot easily
say "please only use salsa" and ignore the bts. If you do, changes are
that the autoremover quickly takes care of your package. This
process/policy is what makes the bts useful to me.
So Michael Stapelberg constructively expressed some discomfort[1] with
the bts. Given that I'm a heavy bts user, I don't quite agree with the
details. On the other hand, I can hardly deny that not everyone is happy
about the current bts-debdiff-based workflow. Improving it certainly is
an important matter. It's just not obvious to me what the future should
look like.
Whatever we change here, it'll make some people unhappy. That is
unavoidable. Very likely, I'm part of those some people, because I
integrate heavily with the bts. That still may be a reasonable
trade-off. Arguing that "no you cannot this, because it works fine for
me" would be making innovation impossible.
It got a bit longer than originally intended. Hope this helps someone.
Helmut
[1] https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
Reply to: