All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Markus Heiser <markus.heiser@darmarit.de>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Sphinx version dependencies?
Date: Fri, 20 Jul 2018 16:43:43 -0400	[thread overview]
Message-ID: <20180720204343.GC27862@thunk.org> (raw)
In-Reply-To: <20180720171020.GI4800@magnolia>

On Fri, Jul 20, 2018 at 10:10:20AM -0700, Darrick J. Wong wrote:
> 
> Well yes, but it's the virtualenv workflow that produced build errors
> for Ted; that's what would seem to need fixing?

What would delight me if there was a fixed docutils and Sphinx version
which is the **only** thing which subsystem maintainers need to test
against.  If it fails for that version, then I reject the patch; and
if it works on that version (say, 1.4.9), and it fails on some other
version that a Distro wants to use for its hermetic build environment
(say, 1.7.5), I can tell them, "not my problem, feel free to send me a
patch that makes things work for 1.7.5, and doesn't break on 1.4.9 ---
or package 1.4.9 for your distro build systems."

I don't really care what the mandated version is --- although given
that Fedora and Debian seem to be using 1.7.5, maybe that's the right
answer, and too bad for the enterprise distro build systems --- that's
why they get paid the big bucks.  I just want to know what I'm obliged
to test against.

So if Documentation/sphinx/requirements.txt is the only thing which is
guaranteed to work, that's fine.  But it might be good to document
that somewhere.

						- Ted

WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Markus Heiser <markus.heiser@darmarit.de>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Sphinx version dependencies?
Date: Fri, 20 Jul 2018 16:43:43 -0400	[thread overview]
Message-ID: <20180720204343.GC27862@thunk.org> (raw)
In-Reply-To: <20180720171020.GI4800@magnolia>

On Fri, Jul 20, 2018 at 10:10:20AM -0700, Darrick J. Wong wrote:
> 
> Well yes, but it's the virtualenv workflow that produced build errors
> for Ted; that's what would seem to need fixing?

What would delight me if there was a fixed docutils and Sphinx version
which is the **only** thing which subsystem maintainers need to test
against.  If it fails for that version, then I reject the patch; and
if it works on that version (say, 1.4.9), and it fails on some other
version that a Distro wants to use for its hermetic build environment
(say, 1.7.5), I can tell them, "not my problem, feel free to send me a
patch that makes things work for 1.7.5, and doesn't break on 1.4.9 ---
or package 1.4.9 for your distro build systems."

I don't really care what the mandated version is --- although given
that Fedora and Debian seem to be using 1.7.5, maybe that's the right
answer, and too bad for the enterprise distro build systems --- that's
why they get paid the big bucks.  I just want to know what I'm obliged
to test against.

So if Documentation/sphinx/requirements.txt is the only thing which is
guaranteed to work, that's fine.  But it might be good to document
that somewhere.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-07-20 20:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-19 18:15 Sphinx version dependencies? Theodore Y. Ts'o
2018-07-19 19:04 ` Darrick J. Wong
2018-07-20  7:30   ` Markus Heiser
2018-07-20  7:30     ` Markus Heiser
2018-07-20 13:12     ` Theodore Y. Ts'o
2018-07-20 13:12       ` Theodore Y. Ts'o
2018-07-20 13:45       ` Markus Heiser
2018-07-20 13:45         ` Markus Heiser
2018-07-20 14:52         ` Theodore Y. Ts'o
2018-07-20 14:52           ` Theodore Y. Ts'o
2018-07-20 16:00           ` Markus Heiser
2018-07-20 16:00             ` Markus Heiser
2018-07-20 16:44             ` Darrick J. Wong
2018-07-20 16:44               ` Darrick J. Wong
2018-07-20 16:58               ` Markus Heiser
2018-07-20 16:58                 ` Markus Heiser
2018-07-20 17:10                 ` Darrick J. Wong
2018-07-20 17:10                   ` Darrick J. Wong
2018-07-20 20:43                   ` Theodore Y. Ts'o [this message]
2018-07-20 20:43                     ` Theodore Y. Ts'o
2018-07-20 21:28                     ` Markus Heiser
2018-07-20 21:28                       ` Markus Heiser
2018-07-21 10:38       ` Jonathan Corbet
2018-07-21 10:38         ` Jonathan Corbet
2018-07-20 15:04     ` Christoph Hellwig
2018-07-20 15:04       ` Christoph Hellwig
2018-07-20 16:28       ` Markus Heiser
2018-07-20 16:28         ` Markus Heiser
2018-07-20 17:08         ` Darrick J. Wong
2018-07-20 17:08           ` Darrick J. Wong
2018-07-20 17:08           ` Darrick J. Wong

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=20180720204343.GC27862@thunk.org \
    --to=tytso@mit.edu \
    --cc=corbet@lwn.net \
    --cc=darrick.wong@oracle.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    /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.