On Fri, 30 Aug 2019 at 09:05:45 -0700, Russ Allbery wrote:
> [git-debcherry] lets you generate the patches for people on demand, but
> they aren't just sitting out there for anyone to look at whenever they want.
I think that's really important from the transparency point of view that
you touched on in a previous mail. If the upstream has an opinion about
a change (either wanting to apply it to their codebase, or thinking
it's wrong and wanting us to stop applying it) and needs the context
of why we made that change, then I think it's important that we make
it as straightforward as possible for them to see what we've done with
their code. IMO part of a downstream maintainer's job is to present the
changes in a way that an upstream can, if not necessarily agree with,
then at least reason about:
* which of their later changes we backported
* which other changes we made, and why
* how we're compiling it (build-time options, etc.)
This is why I try to encourage my colleagues and co-maintainers to
use DEP-3 on their patches, and reorder debian/patches/series with
backports from upstream before upstreamable patches, which are before
Debian-specific changes.
The changes we *used to* make are somewhat secondary: it's important for
downstream maintainers to be able to dig into the history, and it's
occasionally interesting for upstreams to be able to dig into that history
too, but the version(s) we're currently recommending to our users are the
most important.
> Anyway, this is probably only applicable to a minority of upstreams and
> packages, and more upstreams these days would just like all patches as
> PRs.
For all the upstreamable changes yes, but sometimes we have to make
Debian-specific changes that aren't upstreamable, and we should do that
carefully, avoiding the perception that we're randomly forking software
that the upstream maintainer feels strongly about. I'm quite aware
of this as an upstream whose downstreams sometimes make changes that I
wouldn't have accepted, or even changes that I have already rejected.
(It was a particularly surreal experience when I was maintaining dbus in
Debian with a patch included that I had rejected upstream, although
that's fixed in buster.)
smcv
