Chris Lamb writes ("Re: The Difference between debcheckout and dgit and what
theytry to accomplish"):
> Hi Enrico,
> > This reminds me of something that popped up in a dinner discussion a few
> > days ago: mandate documenting workflow in debian/README.source no matter
> > what, and allow to symlink that file to a repository in
> > /usr/share/doc/somewhere/ as we do for common licenses.
>
> I do like the symlink part of this idea as it could mostly address the
> "boy who cried wolf"-like boilerplate concerns that I raised in 2009
> about previous potential overuses of README.source, although in this
> particular case with respect to quilt patches:
I think ideally the git branch format (and expected workflow) should
be made available in machine-readable form.
There are some difficulties. In particular, if the annotation appears
in the git tree object, the annotation would have to be stripped from
the .dsc, and all tools we use to convert/upload/release things would
have to be taught to massage it appropriately. That is a *lot* of
tools. [2]
Otherwise, for example,
apt-get source && cd $p && git init && git add . && git commit
would generate a git branch which tools would hideously mangle.
Similarly for git branches converted/massaaged by other tools (eg
gbp pq, dgit's quilt fixup/conversion, git-dpm, Launchpad,...)
Alternatively this information could live in metadata specifying the
git server (eg vcs-git) or on or near the git server itself.
I'm inclined to suggest that the information should be recorded in the
DEP-14 (maintainer view) tag, or dgit archive/ tag. That would be
findable given any particular branch head. Conversions like the
apt-get rune above would not include such a tag so would be safe.
The information would be wrong when the maintainers change workflow,
in the period between converting the format of salsa#master and the
first subsequent upload, but such a conversion involves a lot of
coordination anyway and that period can be kept short.
Ian.
[1] And by dgit during any needed maintainer view to dgit view
conversion.
[2] IME maintainers of git workflow tools take wildly varying
approaches to requests to change their tools' behaviour, to facilitate
improvements in our source code management. Some tools are
ill-maintained and some of their maintainers are (as might be
expected) quite idiosyncratic, even insular. To get all such git
workflow tools to have some new behaviour would be a big task and
would require serious political backing. And a design predicated on
such a change will cause lossage when older tools are used.
--
Ian Jackson <ijack...@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.
