qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Andreas Schwab" <schwab@linux-m68k.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>
Subject: Re: [PATCH for 5.1] docs: fix trace docs build with sphinx 3.1.1
Date: Tue, 28 Jul 2020 19:40:58 -0400	[thread overview]
Message-ID: <6ec6a79f-fdf5-57b9-50f5-3c02ee9f11d5@redhat.com> (raw)
In-Reply-To: <CAFEAcA8GyXLkt439aYTbNSO_CSoh_Fq0HJeMzYuAkB6RBOfdoQ@mail.gmail.com>

On 7/27/20 4:14 PM, Peter Maydell wrote:
> On Mon, 27 Jul 2020 at 20:52, John Snow <jsnow@redhat.com> wrote:
>> ... Should we say goodbye to Sphinx 1.7.x, or is there a workaround that
>> keeps support from 1.6.1 through to 3.1.1?
> 
> I think we need to keep 1.7.x because it's the Sphinx shipped
> by some LTS distros we support, don't we?
> 

Only if you feel it's important that doc building works using packages 
from the system repo. `pip3 install --user sphinx` works on all of these 
distros, too.

We already somewhat break our promise where Sphinx is concerned for the 
oldest distros on our support list.

> I do feel we probably need to defend our Sphinx-version-support
> more actively by having oldest-supported and bleeding-edge
> both tested in the CI setup...
> 

We could either:

A) Start using a "build venv" that uses specific sets of python packages 
for the build process to pin everyone's build at version 1.6.1

B) Add some sort of pytest/tox/whatever to add a test that does a sphinx 
doc build across multiple different versions, 1.6.1, 1.7.x, 2.0.x, etc.

(I don't think you liked the idea of a Python environment in QEMU taking 
responsibility of Sphinx, though ...)



  reply	other threads:[~2020-07-28 23:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14 16:26 [PATCH for 5.1] docs: fix trace docs build with sphinx 3.1.1 Daniel P. Berrangé
2020-07-14 16:56 ` no-reply
2020-07-14 17:04 ` no-reply
2020-07-26 20:49 ` Andreas Schwab
2020-07-27 19:52   ` John Snow
2020-07-27 20:14     ` Peter Maydell
2020-07-28 23:40       ` John Snow [this message]
2020-07-29 10:37 ` Stefan Hajnoczi
2020-07-29 11:34   ` Daniel P. Berrangé
2020-07-29 14:55     ` Stefan Hajnoczi
2020-09-08 14:55       ` Laszlo Ersek

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=6ec6a79f-fdf5-57b9-50f5-3c02ee9f11d5@redhat.com \
    --to=jsnow@redhat.com \
    --cc=berrange@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=schwab@linux-m68k.org \
    --cc=stefanha@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).