Re: [PATCH] xfsdocs: add epub output

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Jan 12, 2023 at 02:44:01AM +0100, Csaba Henk wrote:
> On 23-01-12 09:10:27, Dave Chinner wrote:
> > On Wed, Jan 11, 2023 at 09:15:57AM +0100, Csaba Henk wrote:
> > > ---
> > >  .gitignore                               |  1 +
> > >  admin/Makefile                           | 13 +++++++++++--
> > >  admin/XFS_Performance_Tuning/Makefile    | 13 +++++++++++--
> > >  design/Makefile                          | 13 +++++++++++--
> > >  design/XFS_Filesystem_Structure/Makefile | 13 +++++++++++--
> > >  5 files changed, 45 insertions(+), 8 deletions(-)
> > 
> > The change looks fine, but why do we need to build documentation in
> > epub format? Empty commit messages are generally considered a bad
> 
> Well, we don't *need*; I just found we *can* (a2x spits it out in a
> split second).
> 
> My perception is that epub has become the de facto standard portable
> publication format for on-screen reading. So I thought it would be
> beneficial to make it available.
> 
> If this is not a consensual stance, it's also a possibility to add
> the epub target, but do not include it in default. Ie. make it
> available on demand.

Does epub support add more dependencies that I have to install?

Not opposed, just curious.

> > thing - the commit message should explain to us why building epub
> > format documentation is desired, what problem it solves, what new
> > dependencies it introduces (e.g. build tools), how we should
> > determine that the generated documentation is good, etc so that have
> > some basis from which to evaluate the change from.
> 
> Sorry; I thought a mere subject suffices if it's obvious what's the
> impact of the patch. I agree that giving context / rationale would be
> useful. I'll add that, according to the approach we settle with (ie.
> whether to include it in default).

Yes please. :)

--D

> Regards,
> Csaba
>