On 22.02.24 10:49, Roger Pau Monné wrote: > On Wed, Feb 21, 2024 at 10:53:49PM +0000, Julien Grall wrote: >> Hi George, >> >> On 21/02/2024 02:55, George Dunlap wrote: >>> On Mon, Feb 19, 2024 at 6:38 PM Jan Beulich wrote: >>>> >>>> On 19.02.2024 11:31, Roger Pau Monné wrote: >>>>> On Mon, Feb 19, 2024 at 06:01:54PM +0800, George Dunlap wrote: >>>>>> One of the questions we had with respect to changing our release >>>>>> practice (for instance, making the process more light-weight so that >>>>>> we could do a point release after every XSA) was, "How many people are >>>>>> actually using the tarballs?" >>>>> >>>>> What would this more lightweight process involve from a downstream >>>>> PoV? IOW: in what would the contents of the tarball change compared >>>>> to the current releases? >>>> >>>> From all prior discussion my conclusion was "no tarball at all". >>> >>> Or at very least, the tarball would be a simple `git archive` of a >>> release tag. Right now the tarball creation has a number of >>> annoyingly manual parts about it. >> At the moment we have the following steps: >> >> 1) Checkout tag >> 2) Create the tarball >> 3) Check the source tarball can build >> 4) Sign the tarball >> 5) Upload it >> >> I managed to script it so I have only two commands to execute (mostly >> because I build and sign on a different host). >> >> AFAIU, your command 'git archive' will only replace 2. Am I correct? If so, >> it is not entirely clear how your proposal is going to make it better. > > IMO building for release tarballs is easier than from a git checkout > (or archive). It's a bit annoying to have to pre-download the > external project sources, now even more as QEMU is using git > submodules. > > Most distro binary builders have infrastructure to deal with all this, > but requires a bit more logic in the recipe than a plain just fetch a > tarball and build from it. I have an unfinished patch series lying around doing the download steps _before_ starting the build. This includes make targets for downloading the required components, or all components if configure should be called afterwards. Creating the tarball after having downloaded all components is trivial. There are a few bugs in the series I didn't have time yet to fix. If someone is interested in working on it, I can post the series. Juergen