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/
