[Pkg-xen-devel] Security updates (Re: git workflow, redux)

[Ian Jackson]

Responding separately here to the part about how security updates are
done (and in particular, what choices we make about what combination
of things from usptream to make into each update):

Hans van Kranenburg writes ("Re: git workflow, redux"):
> On 08/23/2018 08:07 PM, Ian Jackson wrote:
> > I don't think it is realistic to expect the [security patch
> > application process] situation to be different in buster than it
> > was in stretch.  [...]
> > 
> > It's awkward but git-debrebase makes this reasonably straightforward.
> > Doing this stuff with quilt would be nearly unworkable.
> 
> Because of the complexity of the work that's flying by in the XSAs and
> generally in the code, the thing I'm mostly interested in here is which
> approach is the best to end up with a working result for everyone, which
> is the thing that we call 'stable' in Debian.

That is precisely the same consideration Wolodja and I have been using
when deciding how to prepare each security update for stretch.

> Is it giving the stable-X branch to our users, because we know it passed
> all the upstream tests? Or is it cobbling together our own collection of
> changes?

That depends primarily on whether a stable-X branch is available with
the necessary fixes.  Often the right answer is to use the upstream
stable-X branch, but supplemented with patches from advisories.  That
is close to what the upstream security team have been reviewing,
testing, etc.

> But, this is more about how upstream organizes things, how often stable
> releases are tagged and there's more discussion about it upstream, which
> should be participated in (about maturity level of the patch publishing
> process etc), instead of discussing it here.

This is a very active topic upstream.  Debian are not the only
downstream who are complaining that it is very awkward (and, as you
point out, that it can be risky).  We can hope that things will
improve.  But I wouldn't count on it.

Thanks,
Ian.