All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Felipe Contreras" <felipe.contreras@gmail.com>
Cc: "Jeff King" <peff@peff.net>,
	"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 14:00:55 -0500	[thread overview]
Message-ID: <609ad46776dec_6011e208d7@natae.notmuch> (raw)
In-Reply-To: <877dk5tovj.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 11 2021, Felipe Contreras wrote:
> 
> > Jeff King wrote:
> >> On Mon, May 10, 2021 at 11:27:54PM -0500, Felipe Contreras wrote:
> >> > Jeff King wrote:
> >> [...]
> >> > 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.
> 
> Just because I'm developing the latest git.git revision on Debian stable
> that doesn't mean that I'm keen to install the very latest openssl,
> libcurl, asciidoc, C compiler, or whatever other thing we depend on.
> 
> I'm not disagreeing with bumping the dependency in this case (I haven't
> looked into it). I'm just pointing out that in general there's a lot of
> use-cases for e.g. building a latest git on an N year old OS.

I'm not disagreeing with that. The reason I mentioned it is what Jeff
said next:

> > > It's not too hard to install an updated gem, but not quite as nice
> > > as using the system package (it also makes things weird for
> > > building the stable Debian package itself, which would want to
> > > rely only on other packages; but of course any proposed change to
> > > the doc toolchain would be for new versions, and would not get
> > > backported there anyway).

Doing `gem install` solves the problem for whomever wants to build the
latest git in Debian stable.

Building Debian stable packages is something else.

> Of course we can ask these people to just build their dependencies too,
> as I noted in [1] in a past discussion. Whether we bump our required
> dependencies is a trade-off between our own convenience and these sorts
> of in-the-wild builds.
> 
> I'm just saying we should keep this use-case in mind, it's not an all or
> nothing where you either have ancient deps + ancient git or bleeding
> edge deps + bleeding edge git. A lot of people build ancient deps +
> bleeding edge git.

But what is "this"?

 1) Building the latest documentation in Debian stable
 2) Packaging the latest git in Debian stable

If it's 1) then there's no problem: `gem install` does the trick, and in
fact in their CI builds [1] they test with versions of Ruby as old as
2.3, and Debian stable ships with 2.5.

I test my own Ruby code with versions of Ruby as old as 2.0 and there's
rarely any issue. What works with Ruby 2.3 works with Ruby 2.0. Ruby is
not like python (where 3.0 is completely different from 2.0).

If it's 2) then that's where I say: who cares?

> The "just use the built doc tarballs" is only a partial solution, and
> e.g. won't work for someone who's interested in building "next" or
> otherwise applying local patches that have doc changes.

Right, but "just use the built doc tarballs" is not the suggestion for
people trying to do 1).

Cheers.

[1] https://github.com/asciidoctor/asciidoctor/actions/runs/830132862

-- 
Felipe Contreras

  reply	other threads:[~2021-05-11 19:01 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
2021-05-11 12:44               ` Ævar Arnfjörð Bjarmason
2021-05-11 19:00                 ` Felipe Contreras [this message]
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

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

  git send-email \
    --in-reply-to=609ad46776dec_6011e208d7@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=avarab@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.
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.