Hello, I''d like to know why when there is a new advisory you just release a patch instead of a new release. This, in my opinion creates only confusion. For example, if I''m running 4.2.1 I don''t exatly know which patches have been applied. If you say, this is fixed in 4.2.2 I know that if I''m run that version, I''m fine. Is there a real reason because you don''t make a new release? -- Agostino Sarubbo Gentoo Linux Developer
On 25/06/2013 18:07, Agostino Sarubbo wrote:> Hello, > > I''d like to know why when there is a new advisory you just release a patch > instead of a new release. > > This, in my opinion creates only confusion. For example, if I''m running 4.2.1 > I don''t exatly know which patches have been applied. If you say, this is fixed > in 4.2.2 I know that if I''m run that version, I''m fine. > > Is there a real reason because you don''t make a new release?I would be interested if you could provide examples of upstream projects which do issues brand new releases for every security fix, rather than applying the patch(es) to appropriate stable trees. Downstream distros certain do issue hotfixes/updates when they deem appropriate. If there is any confusion regarding patches and versions, please refer to http://wiki.xen.org/wiki/Security_Announcements which provides all details (although I note it is out of date with respect to XSA-57). ~Andrew
On Wednesday 26 June 2013 00:09:54 Andrew Cooper wrote:> I would be interested if you could provide examples of upstream projects > which do issues brand new releases for every security fixTbh, very few project do the same of you, and I usually see the new release in few time... Anyway you didn''t answer to my question.> If there is any confusion regarding patches and versions, please refer > to http://wiki.xen.org/wiki/Security_Announcements which provides all > details (although I note it is out of date with respect to XSA-57).You didn''t understand the point. -- Agostino Sarubbo Gentoo Linux Developer
On Tue, 2013-06-25 at 19:07 +0200, Agostino Sarubbo wrote:> Hello, > > I''d like to know why when there is a new advisory you just release a patch > instead of a new release. > > This, in my opinion creates only confusion. For example, if I''m running 4.2.1 > I don''t exatly know which patches have been applied. If you say, this is fixed > in 4.2.2 I know that if I''m run that version, I''m fine.A new point release will rollup all the applicable security updates issued before that point. In addition all of our releases are tagged in version control, so you can trivially find out what went into it. You could also just run the latest stable-X.Y branch from xen.git. I wouldn''t personally recommend doing so in production but it seems to be a good fit for your requirements.> Is there a real reason because you don''t make a new release?People who deploy and run production systems want a timely, targeted and low risk fix for a security issue, which they can be confident of deploying quickly, with a minimum of disruption to their service and with the lowest possible chance of breakage. A new release would necessarily contain other fixes not related to the security issue and therefore takes longer to produce and longer to test and deploy in order to reach the same level of confidence. I think you will find that this approach to security support is quite common, especially among critical system components. Ian.
On Wed, Jun 26, 2013 at 10:21:34AM +0100, Ian Campbell wrote:> > > Is there a real reason because you don''t make a new release? > > People who deploy and run production systems want a timely, targeted and > low risk fix for a security issue, which they can be confident of > deploying quickly, with a minimum of disruption to their service and > with the lowest possible chance of breakage. A new release would > necessarily contain other fixes not related to the security issue and > therefore takes longer to produce and longer to test and deploy in order > to reach the same level of confidence. >I think what he meant is why not release a new version with only security patches in it, so if the current Xen version is 4.2.2, and there''s a new security issue being found, Xen project would release Xen 4.2.3 with *only* the security fix(es) added on top of 4.2.2. Some projects do that, others don''t. Personally I don''t have a problem with the current model of only adding the security fixes to stable branches, without a new tarball release. -- Pasi
On Wednesday 26 June 2013 16:54:03 Pasi Kärkkäinen wrote:> I think what he meant is why not release a new version with only security > patches in it, so if the current Xen version is 4.2.2, and there's a new > security issue being found, Xen project would release Xen 4.2.3 with *only* > the security fix(es) added on top of 4.2.2.Yes, more or less you centered the point. I don't know if it is correct for you, but if you define 4.2.1 the version with the security fixes could have the name like 4.2.1.x . So it is always the same with the security update -- Agostino Sarubbo Gentoo Linux Developer _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wednesday 26 June 2013 10:21:34 Ian Campbell wrote:> A new point release will rollup all the applicable security updates > issued before that point. > > In addition all of our releases are tagged in version control, so you > can trivially find out what went into it. > > You could also just run the latest stable-X.Y branch from xen.git. I > wouldn''t personally recommend doing so in production but it seems to be > a good fit for your requirements.I''m not a xen user. I manage and coordinate the security bugs on Gentoo Linux.> > > Is there a real reason because you don''t make a new release? > > People who deploy and run production systems want a timely, targeted and > low risk fix for a security issue, which they can be confident of > deploying quickly, with a minimum of disruption to their service and > with the lowest possible chance of breakage. A new release would > necessarily contain other fixes not related to the security issue and > therefore takes longer to produce and longer to test and deploy in order > to reach the same level of confidence. > > I think you will find that this approach to security support is quite > common, especially among critical system components.Yes, in case of package like xen, should be a risk update without have done a better test on e.g. another test machine. Pasi in his mail made a great proposal. I''d like if you considerate it. -- Agostino Sarubbo Gentoo Linux Developer