git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jeff King <peff@peff.net>, Felipe Contreras <felipe.contreras@gmail.com>
Cc: "Martin Ågren" <martin.agren@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	"Bagas Sanjaya" <bagasdotme@gmail.com>,
	"Git Users" <git@vger.kernel.org>
Subject: Re: [RFC suggestion] Generate manpage directly with Asciidoctor
Date: Tue, 11 May 2021 03:03:38 -0500	[thread overview]
Message-ID: <609a3a5a7aa08_5d5d32088@natae.notmuch> (raw)
In-Reply-To: <YJogn8cUtSP/BAbJ@coredump.intra.peff.net>

Jeff King wrote:
> On Mon, May 10, 2021 at 11:27:54PM -0500, Felipe Contreras wrote:
> > Jeff King wrote:
> > > It does create a situation where people like Randall on NonStop might
> > > need to do part of their dev work on another, more mainstream platform.
> > > But I suspect that is already the case.
> > 
> > Or use distributed tarballs with already built documentation.
> 
> For users, yes. But the context above is about people who are
> contributing to Git, and writing their own new documentation. Presumably
> they'd like to build it to see the output.

I'm a developer, I've added 261 lines and removed 212 lines to the
documentation, and I've very rarely built it. Why? Because it takes too
long.

But you were talking about Randall, who I don't know what his role is,
but my bet is that he is a packager. It's not the same thing. Randall
has contributed only one patch to the Documentation, and it was to
install pre-formatted documentation. Precisely what I thought he would be
interested in.

In fact, the bulk of his contribution was to install-doc-quick.sh, which
needs git-htmldocs and git-manpages. Two repositories I didn't even know
existed. So that's yet another option for him.

Of course Randall can say if he sees himself as a developer.

> > > That does make things a little less convenient; Debian stable, for
> > > instance, still has 1.5.8.
> > 
> > And it has git 2.20.1, released at the end of 2018.
> > 
> > I've never understood developers worried about how the bleeding edge
> > would build in ancient platforms, when ancient platforms don't care
> > about the bleeding edge.
> 
> Again, this is about developers. Are there people contributing new
> documentation to Git who are doing so on Debian stable, and would be
> inconvenienced by needing to upgrade their toolchain?

Developers don't need to create (or use) debian packages. They can
simply do `gem install asciidoctor` and be done with it. Some may even
create a docker container to install all the doc toolchain in order to
avoid polluting their main environment.

I for one would start building the documentation more if all I needed is
one dependency.

> > > I'm unclear when support for python asciidoc goes away here. Is it part
> > > of step 6 (because it does not have another way of generating them)? Or
> > > does it live on forever as a non-default legacy system? I'd prefer not,
> > > but as long as we are clear about the primary target and leave it up to
> > > people interested in the legacy to do the compat fixes, that might be
> > > OK.
> > 
> > How about we leave the legacy system in place as an alternative, and
> > decide later what to do with it?
> 
> That's what I was asking.
> 
> Leaving it forever does mean supporting xmlto forever, which complicates
> the Makefile (and that support will bitrot if people are not actually
> building it).

Indeed. If and when it's clear the xmlto part has bitrotten, and
people are happy with the asciidoc toolchain and output, then it can be
obsoleted.

That would be my vote (I don't think there will be a strong need to main
the xmlto parts).

It doesn't need to be decided today though.

-- 
Felipe Contreras

  reply	other threads:[~2021-05-11  8:03 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-07  6:06 [RFC suggestion] Generate manpage directly with Asciidoctor Bagas Sanjaya
2021-05-07 12:02 ` Randall S. Becker
2021-05-07 22:55   ` Felipe Contreras
2021-05-07 22:57   ` brian m. carlson
2021-05-08  1:42     ` Randall S. Becker
2021-05-07 12:27 ` Đoàn Trần Công Danh
2021-05-07 12:47   ` Bagas Sanjaya
2021-05-07 23:03   ` Felipe Contreras
2021-05-08  4:27     ` Bagas Sanjaya
2021-05-07 20:25 ` brian m. carlson
2021-05-07 22:19   ` Jeff King
2021-05-08  4:22     ` Bagas Sanjaya
2021-05-09  8:20     ` Martin Ågren
2021-05-09 18:46       ` Felipe Contreras
2021-05-10 18:43         ` Martin Ågren
2021-05-10 22:24       ` Jeff King
2021-05-11  4:27         ` Felipe Contreras
2021-05-11  6:13           ` Jeff King
2021-05-11  8:03             ` Felipe Contreras [this message]
2021-05-11 12:44               ` Ævar Arnfjörð Bjarmason
2021-05-11 19:00                 ` Felipe Contreras
2021-05-11 19:09                   ` Jeff King
2021-05-11 20:22                     ` Felipe Contreras
2021-05-11 23:14           ` brian m. carlson
2021-05-12  1:44             ` Felipe Contreras
2021-05-11 18:45         ` Martin Ågren
2021-05-11 19:07           ` Jeff King
2021-05-11 19:11             ` Martin Ågren
2021-05-11 20:14             ` Felipe Contreras
2021-05-11  9:04       ` Jean-Noël Avila
2021-05-11 18:54         ` Martin Ågren
2021-05-07 23:35   ` Felipe Contreras
2021-05-07 23:57     ` brian m. carlson
2021-05-08  3:10       ` Jeff King
2021-05-08  3:23         ` Jeff King
2021-05-09  0:22         ` brian m. carlson
2021-05-09  8:29     ` Martin Ågren
2021-05-07 22:48 ` Felipe Contreras

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=609a3a5a7aa08_5d5d32088@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=bagasdotme@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=martin.agren@gmail.com \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    /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).