Sean Whitton <[email protected]> writes:

> Hello,
>
> Simon Josefsson [08/Jan  8:41am +01] wrote:
>> I think this will be revisited in discussion again and again, because it
>> is not a simple technical matter with a simple solution, but there is
>> one approach that I didn't see suggested how to deal with this:
>>
>> Instead of rewriting git history: prune it.  That is, get upstream to
>> remove offensive non-DFSG material from their git project in the first
>> place, and then start an Debian upstream-code branch from that commit.
>>
>> Yes, older branches will still contain non-DFSG content, but at least
>> the "modern" branch that we use for building will not contain non-DFSG
>> content, even in the git history.
>>
>> I think this is an acceptable and practical approach that will meet even
>> the most stringent reviews from anyone who is concerned about having
>> non-DFSG content in a git branch.
>>
>> This approach can also be adopted to deal with really large upstream git
>> projects.
>>
>> As for what to do with old branches, it doesn't really matter.  There
>> are fewer reasonable arguments for not preserving factual history.
>> (Although snapshot.debian.org's removal of some old files may be
>> reasonable, or it may not..)
>
> Well, yes, but upstram will probably just refuse to do that.

I have had a couple of examples of getting upstream Go projects to do
that, and I don't recall anyone refusing so far.  [1] is the closest to
a refusal that I have got, but it seems more lack of time (and lack of a
concrete patch).

Examples has included pre-compiled binaries, unnecessary vendored code,
third-party non-free documentation, and copies of the
https://developercertificate.org/ file.  And maybe some other corner
cases that lintian complained about that I forwarded upstream.

There are known philosophical disagreements, for example around the GNU
Emacs manual, but otherwise I think many upstreams are supportive to
make their git repositories directly usable for downstream.  Debian
isn't alone to worry about these aspects.

/Simon

[1] https://github.com/Foxboron/sbctl/issues/477

Attachment: signature.asc
Description: PGP signature

Reply via email to