Hello Ian,
On Wed, Oct 19, 2016 at 09:31:28PM +0100, Ian Jackson wrote:
> Sean Whitton writes ("Bug#840153: Should have various tutorial manpages"):
> > control: tag -1 +patch
> >
> > Please find attached git-am(1)-amenable patches adding some pod2man
> > infrastructure, and dgit-maint-merge(7).
>
> Thanks! I really like your new manpage.
Thanks for responding to my patch submission!
> And you should add it to the Makefile in the same commit as you add
> the file, or you create a commit that doesn't build.
> BTW I'm just as happy with git branch on a server as I am with git-am
> patches.
I'll ensure that I don't commit stuff that doesn't build, now that I
know I can submit patches by publishing a branch somewhere. The patches
were ordered the way they were so that I could easily --amend the patch
that adds the manpage.
> I have also made a few changes to the manpage, which I hope you will
> approve of.
I don't understand the two non-trivial changes you've made to the text
of the manpage. I hope you can explain further.
(1) the addition to the "initial debianisation" section:
I don't think this workflow should explicitly recommend going anywhere
near upstream's tarballs, except in the case where upstream doesn't use
git.
A package maintainer might have a good reason to do a consistency check
that upstream's released tarballs match their signed tags. To my mind,
this is akin to all the other testing that a package maintainer
performs, such as installing it and seeing if it segfaults.
However, the way that you have written the text suggests that that check
is an integral part of using the merge workflow. I don't think it
should be. Although it's true that you _can_ use upstream's tarball if
it is identical to the tag, there is absolutely no need to do so. This
is the kind of busywork we're trying to avoid. Just `git archive` and
forget about it. The gbp documentation, too, discusses the case where
you "don't care" about the tarballs upstream releases.
I like the pointer to "When upstream releases only tarballs" for the
purposes of performing this consistency check, though. So I'd like to
suggest deleting your "When upstream tags releases in git and releases
identical tarballs" section, and instead appending the following text to
the "When upstream tags releases in git" section:
(It is often a good idea to confirm that upstream's released
tarballs match the release tags. A convenient way to do this is to
import the tarball as described in "When upstream releases only
tarballs", using a different value for 'upstream-tag', and then use
git-diff(1).)
(2) the removal of the advice to use --squash:
Could you explain why you think this was bad advice? It ensures that
the bad refs are *not* pushed to dgit-repos. I agree with your addition
of contact details for the relevant archive administrators.
> > (I'm keen to retain the authorship information in the actual
> > manpage, but you might not like how I've edited d/copyright, so I
> > made that a separate patch.)
>
> Right. I have changed this a bit. I hope you like it.
All fine.
--
Sean Whitton
signature.asc
Description: PGP signature
