Hi,

On 7/15/19 4:42 PM, George Dunlap wrote:
> On 7/15/19 3:23 PM, Jan Beulich wrote:
>> On 15.07.2019 16:11, George Dunlap wrote:
>>> There was a long discussion about security patches, with the general
>>> proposal being that we should cut a point release for every security issue.
>>
>> Interesting. Looks like in politics that until a decision fits people
>> they keep re-raising the point. Iirc on a prior meeting (Budapest?)
>> we had settled on continuing with the current scheme. Were there any
>> new arguments towards this alternative model?
> 
> Well I don't know if there were any new arguments because I don't
> immediately remember the old discussion.  Do we have a summary of the
> discussion in Budapest, with its conclusions, anywhere?
> 
> The basic idea was that:
> 
> 1. Most distros / packagers are going to want to do an immediate release
> anyway.
> 
> 2. Distros generally seemed to be rebasing on top of staging as soon as
> the XSA went out anyway (and ISTR this being the recommeneded course of
> action)

FYI, In Debian, we only ship the stable branch, not the staging branch.
Better safe than sorry.

And yes, this means there's a delay, and it's not immediate, etc.

Well, at least since I have been involved. In the past security update
packages were made by applying patches manually on top of older (like,
4.4.1 instead of 4.4.x) frozen versions, but we decided that "trying to
assemble our own subset of the patches is riskier than taking upstream's
collection".

The Debian Release Team allows us to upload newer upstream versions
during a security upload for Xen, which is officially not allowed in
Debian stable. One of the things that obviously help with being able to
keep doing this is the "track record" of the quality (expecially
regression testing) of the stable-4.x branches.

Currently, our package versions mostly look like e.g.
4.11.1+92-g6c33308a8d-1, instead of a nice simple version number. For me
this is fine, but I can understand that for an end user it would just
look nicer (and feel better perception-wise) to get a 4.11.x package.

So just for that reason I would be all +1 for more tagged releases.

> So for all intents and purposes, we have something which is, in fact, a
> release; all it's missing is a signed tag and a tarball.
> 
> Obviously there are testing implications that would need to be sorted
> out before this could become a reality.
> 
> In any case, the ball is in the court of "VOLUNTEER" to write up a
> concrete proposal which could be discussed.  You'll be able to raise all
> your concerns at that point if you want (although having a sketch would
> of course be helpful for whoever is writing such a proposal).

Hans

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Reply via email to