Xen Summit 2023 Design Session: Stable Releases

[Henry Wang <Henry.Wang@xxxxxxx>]

Hi all,

Below is the note that me and Luca have taken for the stable release design 
session.
Thanks Luca for sharing his notes.

Jan: for long time we've done time-based stable releases, but overtime
     it is brought up purely time based release is not a good idea.
     Sometimes because of XSA, sometimes backported patch does not apply
     cleanly. One possible solution is one stable release per XSA, but we
     need to consider we need to be practical, too frequent releases brings
     problem for people.
     One of the problem is, that patches are not public, before the embargo,
     so the public tree cannot be prepared for the release until the embargo
     expires. Maybe some preparation can be done upfront?
Jan: Should we change the stable release strategy, Do people think that we 
     should change timely cadence of the release?
B: This is only for stable release?
Jan: Yes, Major release are going to stay as they are, stable release are
     the subjects.
G: We need to know what the users of stable releases, what do they want
A: Current thing is good for Qubes
A: I've been informed that some customers in mailing list wants more frequent
   release, fedora, etc.
A: I know some projects cut releases once per security fix. I got the 
   impression from customers that they want one release per security issue.
   what they want is after the embargo, they can pull the tag with the security
   fix.
B: I am on the yocto side, having downstream patches stored in yocto is not 
   good. Bumping versions is easier.
A: sometimes the people preparing the tarball of Xen is not technically
   "users". The point of Xen security team is to deliver the security fixes
   as easy as possible to everywhere.
Jan: Sometimes it is hard to get the binaries on time after the embargo. We 
   need to have a model to have binaries right after the embargo
B: Most of the time yocto is in the middle. Xen version is bumped in yocto 
   every yocto release, by then the XSAs are pulled in. for yocto it is not
   possible to maintain the single XSA by downstream patches
Jan: why dont we do partial release, tags but no tarballs
A: that would be satisfactory for the people who complains, normally no one
   uses tarballs now. This would be entirely fine.
G: We can ask who is using the tarballs, we can ask LF.
Jan: dependency for the leaf trees and qemu
B: tarballs is useful for students and new starters without Xen knowledge.
Julien: We can use gitlab to make the tarball?
A: tarballs from Xen dir is not 100% the tree. It contains more such as qemu
   dep so not be directly done by gitlab.
B: we need to be realistic about what we can do in short terms. The number of
   tarball downloads would be the initial question.
Jan: mini-os
A: Just add a tag for sub-releases in xen.org would be good for most of people
   complaining.
G: we can ask in xen-devel to collect feedback about tarball. maybe a survey.
B: You can apply the tag as soon as you apply the XSA. We can also not limit 
   this way to only XSA.
Jan: Too many releases?
A: we can have even more digits in the release numbers
Jan: for interim releases, make no announcements, no tarballs, no website, but 
   for normal stable releases, do them all.
A: Users do not really cares about tarballs, websites. 
G: we can put more info about these release in the new website or gitlab
   instead of xenbits website.
Julien: Can we check the number of downloads?
A: We check the number of downloads, if nobody care, we announce that we move
   the website etc. about the releases to new places.
G: also ask users what do they need.
B: You need a phase out. You cannot do all the movement instantly. You do it 
   step by step with proper guidance for users.
Jan: If we do more frequent release, we cannot ping people about backports as a 
   new release is coming, because this means revealing there is a security hole
   in the code and the XSA is coming. we need to ask for more frequent of 
   backports and probably give Anthony commit privileges for maintaining the 
   tools.
G: Summary: if we don't have to do the tarballs for sub release, it is fine. If 
   we have to try to figure out who is consuming the releases as an 
understanding,
   then start from there.
   Putting a tag will solve the complaints from people, there is a general  
agreement.
   Check the number of downloads, put something out something in a public page 
   to ask feedback on the retirement of the tarball. So we should phase out 
   that, in an agreed time.
Jan: Discuss in community call

Kind regards,
Henry