Ian Jackson writes ("Survey: git packaging practices / repository format"):
> While trying to write the dgit FAQ, and some of the relevant docs, it
> has become even more painfully obvious that we lack a good handle on
> what all the different ways are that people use git to do their Debian
> packaging, and what people call these formats/workflows, and what
> tools they use.
>
> Can you please look through the table below and see if I have covered
> everything you do ?
Thanks to everyone who responded. I (with some help from Sean and
some review from Sam) have worked the answers into a wiki page:
https://wiki.debian.org/GitPackagingSurvey
Unfortunately due to bugs in the Debian and Wiki CSS styles, it is
displayed very suboptimally unless you log into the wiki and set your
style to "Classic". (I have filed bug reports.)
It's a bit fiddly to edit because the main table contains so much
information, including all the footnotes. If you spot errors and
omissions, feel free to respond by private email rather than editing
the wiki page, and I will take care of it. (Please CC Sean too.)
I think everyone's [1] responses are in that table. "Only" 11 basic
git branch formats, times 4 methods for handling upstream code...
Please let us know if we have missed one. It is probably better if
you ask us rather than just adding it, unless you're sure that what
you are adding isn't the same as one of the existing ones. In
particular it seems that "unapplied" is used by a large number of
people with disjoint tooling and disjoint terminology.
It seems likely that a lot more explanatory footnotes are going to be
needed.
I invented names for the branch formats. I am open to suggestions for
better names. Terminology is important. The more common formats
(earlier in the table) need short names; I went for longer names
further down.
I hope you all won't mind too much that Sean and I have privileged our
own point of view, in the columns which contain value judgements, and
that we hope to retain that property of the page.
I intend to collect comments/corrections for a week or so, and then I
will post again to d-d-a or write a blog post or something.
Thanks,
Ian.
[1] This does *not* include the one response from a Debian downstream.
The task of being a Debian downstream is rather different and it
doesn't make sense to try to represent that in the same table.
(Having said that, I should emphasise that I am very keenly interested
in helping Debian downstreams. That has been a major motive for my
work on dgit etc. It's just that this particular information doesn't
fit here.)
