From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "Todd Zullinger" <tmz@pobox.com>,
"Arnout Engelen" <arnout@bzzt.net>,
git@vger.kernel.org, "Martin Ågren" <martin.agren@gmail.com>,
"Jeff King" <peff@peff.net>
Subject: Re: [PATCH] doc: make HTML manual reproducible
Date: Wed, 02 Dec 2020 17:33:46 -0800 [thread overview]
Message-ID: <xmqqy2ifisg5.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <X8gnItjchqX4wwmt@camp.crustytoothpaste.net> (brian m. carlson's message of "Wed, 2 Dec 2020 23:45:38 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2020-12-02 at 16:07:55, Todd Zullinger wrote:
>> brian m. carlson wrote:
>> > If we want this to be effective, then yes, people will need to upgrade.
>> > But if they're happy with the old behavior on ancient systems, that
>> > shouldn't be a problem.
>>
>> Indeed. Is it worth mentioning this at all in INSTALL?
>> Something like:
>>
>> - The minimum supported version of docbook-xsl is 1.74.
>> + The minimum supported version of docbook-xsl is 1.74. For consistent
>> + IDs in the HTML version of the user-manual, 1.79.1 or newer is
>> + necessary.
>>
>> perhaps?
>
> I don't know that that's even necessary. Anyone doing reproducible
> builds is already aware of the required versions in order to do a
> reproducible build, and I don't think the average user is going to be
> super interested.
>
> We can if you feel strongly about it, but I don't personally see it as a
> big deal.
I tend to agree.
The tool being lenient and ignoring a parameter from the future
makes things very simple, and the way the patch is structured,
"stable ID" is not even a build option the builder can enable.
For some version of the toolchain, the option means stable ID and
some older version, it does not mean anything, and that is fine.
We ship our Makefile with "CFLAGS = -g -O2 -Wall" and we do not say
things like "Such and such optimizations are only available if you
use GCC newer than version X.Y"; it is fine to treat the "--param"
the same way here.
next prev parent reply other threads:[~2020-12-03 1:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 9:50 [PATCH] doc: make HTML manual reproducible Arnout Engelen
2020-12-01 15:41 ` Todd Zullinger
2020-12-01 19:18 ` Martin Ågren
2020-12-02 1:54 ` Jeff King
2020-12-01 19:27 ` Junio C Hamano
2020-12-01 19:57 ` Martin Ågren
2020-12-02 0:36 ` brian m. carlson
2020-12-02 16:07 ` Todd Zullinger
2020-12-02 22:35 ` Junio C Hamano
2020-12-02 23:45 ` brian m. carlson
2020-12-03 1:33 ` Junio C Hamano [this message]
2020-12-03 2:00 ` Todd Zullinger
2020-12-03 2:31 ` Re* " Junio C Hamano
2020-12-03 8:07 ` Arnout Engelen
2020-12-02 0:41 ` brian m. carlson
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy2ifisg5.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=arnout@bzzt.net \
--cc=git@vger.kernel.org \
--cc=martin.agren@gmail.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=tmz@pobox.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).