Re: The Difference between debcheckout and dgit and what they try to accomplish
Hi Sam,
On Sun, Jun 16, 2019 at 08:08:51PM -0400, Sam Hartman wrote:
> Ian> That depends, I think, on whether you are trying to (a) join a
> Ian> maintainer team, or do "maintainer-like" work; or, (b) do
> Ian> cross-archive work with small changes to many packages, or
> Ian> archive-wide testing, or similar.
>
> Ian> Any case where the change you want to make is simple, but you
> Ian> want to make it to many packages, is much easier to achieve
> Ian> with a dgit-based NMU workflow.
>
> Ian> RC bugfixing and other kinds of "passer-by" QA work is usually
> Ian> easier with dgit too. You only need to understand the bug, and
> Ian> the relevant parts of the package, not hold some git workflow
> Ian> stuff in your head too.
> Apologies for being a bit repetative.
>
> I understand this is your opinion. I am not sure this is generally
> accepted. What I think I'm hearing from people is that they want to
> actually be able to get closer to being able to change maintainer
> sources than is supported by patches into the bts.
As someone who performs archive-wide changes, I fear I need to somewhat
support Ian's view here. If you are making small changes to many
packages, the maintainer's git tree is not the thing you want to use.
In that kind of situation, dealing with commits that are not yet
uploaded is a disadvantage to your performance. Having to figure out the
maintainer's workflow is a disadvantage to your performance.
My personal conclusion here is that I send patches via the bts. It may
be suboptimal from a maintainer pov (some express a strong preference to
salsa merge requests). Whether I use apt-get source and debdiff or dgit
and git format-patch is a detail on my side.
Still, vcs-git is not my preferred interface to the archive, because its
lack of uniformity makes using it unproductive for me.
I hope this data point helps a little
Helmut
Reply to: