Re: The Difference between debcheckout and dgit and what they try to accomplish
I haven't really organised my thoughts and have been travelling a lot
and am very tired, so this is a bit bitty. I may respond more
usefully in a day or two:
Sam Hartman writes ("The Difference between debcheckout and dgit and what they try to accomplish"):
> Debcheckout allows you to get the latest version of the maintainer's
> preferred branch.
"debcheckout" is just a convenience script for getting at whatever
Vcs-Git provides. In this context I should note that "dgit clone"
will set up a git remote called "vcs-git" which you can "git fetch",
to access the same thing[1] as "debcheckout" gives you.
[1] There is a problem that the Vcs-Git metadata is in the wrong place
(like the Maintainer and Uploaders fields are) with complicated
implications in the presence of skew. (Some of these you mention.)
> If you want to contribute to future development in Debian and make
> things easy for the maintainer, it seems like this is the best tool we
> have today.
That depends, I think, on whether you are trying to (a) join a
maintainer team, or do "maintainer-like" work; or, (b) do
cross-archive work with small changes to many packages, or
archive-wide testing, or similar.
Any case where the change you want to make is simple, but you want to
make it to many packages, is much easier to achieve with a dgit-based
NMU workflow.
RC bugfixing and other kinds of "passer-by" QA work is usually easier
with dgit too. You only need to understand the bug, and the relevant
parts of the package, not hold some git workflow stuff in your head
too.
Also: if all you are planning to do is prepare and test a patch, then
usually the easiest workflow is dgit clone followed by some
git-format-patch. I have submitted many patches this way and no-one
has seemed to think them inconvenient.
> Advantages:
>
> * You get to see things in the maintainer's work flow. You can submit
> patches in the form most familiar to the maintainer.
You say "submit patches". Maybe you mean "submit changes" ?
If you intend to submit *patches*, I think git-format-patch on a
dgitish git branch will do something that is (1) very standard and
expected by a maintainer and (2) easy for the maintainer to
incorporate.
However, what you cannot do without grappling with the maintainer's
workflow is submit a salsa git merge request. I think it would be
possible to improve this - see below.
> * You get to see ongoing development that may not have made it into
> Debian yet.
This may or may not be an advantage, depending on what you are trying
to do.
If we had the right metadata, we could automatically synthesize a dgit
view from the salsa maintainer branch, as desired. But what you would
do with that next is not 100% clear to me...
> * You may see branches that have never been (and possibly never will be)
> in Debian.
This is unrelated to using the debcheckout branch vs using the dgit
clone branch. dgit makes access to the debcheckout history easy.
So this is nothing to do with `dgit clone' vs debcheckout.
> Compare and contrast with dgit clone. Dgit always (assuming there are
...
> * Regardless of what maintainer work flow and data model are used, you
> get a consistent way of interacting with the sources.
You missed:
Regardless of what maintainer work flow and data model are used, you
can prepare completely competent
- NMU
- QA upload
- patches for sending to the BTS
without interacting with the maintainer workflow, with dgit clone.
> * May give you history sufficient for viewing without you needing to
> understand how the maintainer works with git. Interacting with those
> commits may sometimes require knowledge of work flows other than
> dgit's native work flow/data model. Example: you can probably review
> the history enough to read a patch. But cherry-picking patches (or
> reverting) from maintainer view commits may sometimes require
> knowledge beyond standard git knowledge.
Whether maintainer view commits can be "git-revert"'d or
"git-cherry-pick"'d does indeed depend on the maintainer's workflow.
I don't think this problem is avoidable, other than by forbidding
workflows which do not have whatever properties are desirable.
> * When the dgit view is not the same as the maintainer view,
> contributing merge requests requires knowledge on your part or that of
> the maintainer. You always have the bts and raw patches as a
> fallback, but it is often easier for maintainers to process things
> closer to their workflow.
As a matter of equity, I think it should be up to the maintainer to
deal with their workflow. They chose it.
Unfortunately we lack a standardised way for a submitter using a dgit
view to present a branch with their proposed changes.
If we did, then the maintainer could use manual processing, or
tooling, to integrate the patches in whatever way they prefer.
To do this on salsa might need some special salsa behaviours.
We would of course need a way to turn "sane" (dgit view) git commits
back into maintainer view, for each maintainer view. dgit already
knows how to turn them into `3.0 (quilt)' debian/patches, andn of
course the maintainer view tools already have this ability. So this
is "just" a question of the right interfaces and glue.
> * History diverges from maintainer's history if dgit push is never or
> not always used.
This is not a disadvantage if dgit push is used. (It is sufficient if
dgit push is "usually" used.) As you know, IMO there are other
reasons why dgit push should always be used.
> Conclusions
> ===========
>
> I think that for the discussion I'm hoping to start soon, we're focused
> on development within Debian. That is, we do care about code not yet
> released to the archive. We do care about getting future changes
> integrated, possibly even with little action on the part of the
> maintainer.
I think these things are important but:
for the salsa discussion coming out of the DPL campaign
I think you are narrowing the scope unduly, perhaps because you
already have an idea what kind of a solution you want, or because you
want to solve some problems and leave others for later.
Obviously it's up to you what you want to prioritise but I think we
need a solution-neutral problem statement.
For me, that is:
* There is far too much friction and makework caused by Debian's
antiquated source code management practices.
Then the question of your "within Debian" scope becomes a question of
values, doesn't it ? Do we privilege our own convenience, over that
of our users and downstreams ?
Or will we adopt a framing of the conversation that allows us to
consider not only how proposals will affect us, but also how they will
affect others, and whether they will close of ways to improve the
lives of our downstreams ?
I think the only way to square this circle is to always provide *both*:
keep the idiosyncratic maintainer view, but fully support (both
politically, and with technology) the dgit view.
This involves a lot of conversion and so on but that can (and largely
has been) automated. It is work that computers are good at.
> I think the question of finding sources for binaries and of users having
> a uniform approach for making changes is valuable. It's just not the
> focus of the discussion I said I would have during the DPL campaign.
> I'm not even sure which is more valuable: I don't think all the people
> involved in the debian-vote discussion earlier this year understood the
> difference adequately.
Unfortunately I don't think it is possible to have the conversation
about how to reduce within-Debian friction without at least
considering how the proposals support or impede the goal of providing
users the source for the code on their computers.
> What I do know is that I think I'm already worried about whether the
> discussion is too big. I'm going to try and focus on what I said I'd
> focus on because that's valuable. There are other things that are also
> valuable; by trying to narrow my own thinking in this instance I'm
> trying not to make a judgment about them.
That's not going to be possible because some possible answers to what
you call "the salsa discussion" make it harder to solve our users'
problems.
But, having said all that: I do want to be clear that I do not feel
that maintainers in general ought to be using `dgit clone' or `dgit
fetch' except to incorporate NMUs.
Err, too many negatives. Let me try that again:
I don't expect a maintainer to necessarily use dgit clone. Nor do I
expect them to use debcheckout, either.
When (considering) joining a maintainer team, dgit clone followed by
`git fetch vcs-git' is probably a good starting point, but to push to
the actual repo you do need to clone the ssh url which Vcs-Git doesn't
contain. So you're going to have to `git clone' and c&p from salsa.
So `debcheckout' vs `dgit clone' is not the most interesting question.
HTH.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: