Stefan Sperling wrote on Wed, 28 Aug 2019 12:07 +00:00:
> Also, users would have a much harder time trying to verify what they
> are actually running.
Did you see the part where I specifically proposed to release a patch
that fixes the issue _and_ bumps SVN_VER_PATCH? (The patch can also add
a new hunk to the top of CHANGES.)
> I believe this approach would make things harder for downstream consumers.
> They would need to track new Subversion releases as well as patches, so we
> would be shifting more work onto them. This would be unfair on our part,
> even given our current predicaments. We should not be offloading our own
> release engineering work onto other projects.
> Downstream processes are optimized towards the general case across the
> software ecosystem, which is updating to a new release which contains
> a bunch of fixes.
> So I would prefer a new release, together with an updated CHANGES file
> which documents the problems we fixed. Even if it's a few weeks late.
> That way, downstreams won't have to adjust their existing process.
I expect most if not all downstreams are perfectly capable of cherry-picking
a single patch from upstream onto their package. In Debian that's as
easy as upgrading to a new upstream tarball (there are automations for
both of these tasks).
I do concede that if we had just a single release format, tarballs,
that'd be easier on downstreams, but I do not accept that releasing
patches would place an unreasonable burden on downstreams.
Come to think of it, this is exactly what we _already do_ for people on
the pre-notifications list: we don't send them tarballs, but patches.
Actually, I remember that we _used_ to send them tarballs, to
password-protected download pages, but we switched from that to just
sending signed advisories, and I don't recall any complaints about that.
Received on 2019-08-29 02:44:16 CEST