The Difference between debcheckout and dgit and what they try to accomplish
I'm trying to organize my thoughts leading towards a discussion about
git on salsa.
Last month we had a wide ranging discussion that started from a
discussion of preferred formats for git branch structure.
During that discussion, we explored the differences in what a tool like
debcheckout gives you vs a tool like dgit.
Here's my understanding of those differences. I'd appreciate comments
on whether I've accurately understood things as well as more general
comments.
Debcheckout allows you to get the latest version of the maintainer's
preferred branch.
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.
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 get to see ongoing development that may not have made it into
Debian yet.
* You may see branches that have never been (and possibly never will be)
in Debian.
Disadvantages when contributing to future Debian development:
* May not work at all or may provide out of date information if the
vcs-git is outdated etc.
* We have many different git work flows and data models. You may not be
familiar with or like the one the maintainer uses.
* It may not be obvious how to build the sources.
Additional Disadvantages for other use cases:
* It may be challenging to find the source corresponding to binaries you
have
Compare and contrast with dgit clone. Dgit always (assuming there are
no dscs it cannot process) will give you a uniform git view of the
package in the Debian distribution of your choice. It may give you
history, which may be more or less complete, depending on when and how
often dgit push has been used.
It is well defined how to build a dgit view of a source package.
Advantages:
* Lets you as a downstream or user get the source to modify the binaries
you have so you can make changes.
* Regardless of what maintainer work flow and data model are used, you
get a consistent way of interacting with the sources.
* 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.
Disadvantages for Debian Development:
* Only gives you code that has actually been uploaded to the archive.
* 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.
* History diverges from maintainer's history if dgit push is never or
not always 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.
That is, for the salsa discussion coming out of the DPL campaign, we're
focused more on those use cases than on finding the source to a given
binary. And we explicitly do care about how proposed changes get into
the git data model/workflow that the maintainer uses.
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.
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.
Reply to: