Sean Whitton writes ("Re: Bug#840153: Should have various tutorial manpages"):
> On Wed, Oct 19, 2016 at 09:31:28PM +0100, Ian Jackson wrote:
> 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.
Aha. Are you aware of
git rebase -i --autosquash
?
> I don't understand the two non-trivial changes you've made to the text
> of the manpage. I hope you can explain further.
I think you may mean you don't agree :-).
> (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).)
Sure. Would you care to add that as a commit on top of my branch ? I
don't really mind flail in the git history if the intervening commits
pass the tests and don't contain garbage.
You might want to mention that if you do this check, you might as well
use the upstream tarball rather than `git-archive'.
> (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 don't think this is a sufficiently robust way of responding to the
discovery of harmful and/or legally dangerous objects in a public git
history.
If the discoverer takes your approach, these objects will remain on
their own computer, which is itself dangerous.
The objects are very likely to make their way onto the dgit git server
at some point, if only because someone binds the upstream history into
the dgit history (which one might well do without looking at it
particularly closely). Or because someone doesn't notice some time
when they are preparing a new upstream version.
To prevent this, at the very least, the dgit git server should be
configured to reject the bad objects. This requires administrator
intervention.
The same objects are probably already on alioth. So someone needs to
talk to the alioth admins perhaps.
Furthermore, if there _are_ such legally dangerous in a project's git
history, then the project's upstream will probably want to know about
it too! Ideally the whole project's git history would be rewritten by
everyone in a coordinated way, and everyone would know to wipe the bad
data from their computers.
Done properly, this all gets quite complicated, and perhaps political,
and the problem might need to not be broadcasted widely, as well. It
might involve taking urgent legal advice.
I really don't think we as a project could leave one of our individual
contributors to deal with such a problem by themselves, as best they
can. That would be a doing them, and everyone else, a gross
disservice.
Note that by "legally dangerous", "harmful", or whatever we are
talking about data that might get you locked up or harassed or
something. Examples would be child sexual abuse images, bomb-making
manuals, military or diplomatic secrets, etc.
We don't mean things where the copyright licence is unclear, missing,
or widely breached, unless the copyrightholder is pursuing it or
likely to do so. (Examples of the cases where the copyrightholder is
likely to pursue it include are proprietary commercial music
recordings - and films and TV programmes, although those are typically
much larger than you could hide in a git repo.)
Legally dangerous things do not not normally occur in software git
histories. If they do them someone is probably playing games to make
some kind of point.
So luckily this is pretty much a hypothetical problem.
Another reason why I don't like the advice to squash is that people
are not always very good at distinguishing different categories of
problematic data. The distinction between "non-free" and "contrib"
and "no clear redistribution licence so can't be in non-free" already
causes trouble.
I think if we give the advice you propose there would be a significant
number of cases where people would throw away the upstream history for
harmless blemishes. We'd be encouraging a hesitant user to go to
trouble in order to make the world a worse place. So the flipside
reason (for telling the user to ask for advice) is that often the user
will just need reassurance.
Ian.
--
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.
