All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Julien Grall <julien@xen.org>
Cc: George Dunlap <george.dunlap@cloud.com>,
	Jan Beulich <jbeulich@suse.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	committers@xenproject.org, Kelly Choi <kelly.choi@cloud.com>
Subject: Re: Stats on Xen tarball downloads
Date: Thu, 22 Feb 2024 10:49:23 +0100	[thread overview]
Message-ID: <ZdcYo3sGHVYaP6kM@macbook> (raw)
In-Reply-To: <0936a6c5-bac2-4de2-9155-1722d3bb28ca@xen.org>

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 <jbeulich@suse.com> 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.

Thanks, Roger.


  reply	other threads:[~2024-02-22  9:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-19 10:01 Stats on Xen tarball downloads George Dunlap
2024-02-19 10:31 ` Roger Pau Monné
2024-02-19 10:38   ` Jan Beulich
2024-02-21  2:55     ` George Dunlap
2024-02-21 22:53       ` Julien Grall
2024-02-22  9:49         ` Roger Pau Monné [this message]
2024-02-22  9:56           ` Juergen Gross
2024-02-19 15:34 ` Elliott Mitchell
2024-02-21  2:52   ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZdcYo3sGHVYaP6kM@macbook \
    --to=roger.pau@citrix.com \
    --cc=committers@xenproject.org \
    --cc=george.dunlap@cloud.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=kelly.choi@cloud.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.