| Message ID | cover.1734734612.git.martin.agren@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Asciidoctor fixes for 2.48.0 | expand |
Martin Ågren <martin.agren@gmail.com> writes: > The Asciidoctor build of the documentation regressed a bit with > a38edab7c8 (Makefile: generate doc versions via GIT-VERSION-GEN, > 2024-12-06). > > I think these issues and fixes are fairly orthogonal to the recent > discussions beginning at [1], with fixes being discussed beginning at > [2]. I've tested these here patches on top of that series' v1 [2] > rebased onto a38edab7c8, as well as on top of its recent v3 [3] as > applied on the indicated base-commit. > > With these patches, I can use > > make USE_ASCIIDOCTOR=YesPlease doc > > and > > ./doc-diff --asciidoctor <...> <...> > > with similar results as pre-a38edab7c8. > > On top of current master [4], these patches help, but for "doc-diff", > the GIT_VERSION injection is still broken (as expected, that's why > [1,2,3] exist). These here patches don't refer to doc-diff or those > other patches [2,3] and could go in independently or on top. > > These patches are based on [3] applied on its indicated base-commit. > > [1] https://lore.kernel.org/git/20241218113324.GA594795@coredump.intra.peff.net/ > > [2] https://lore.kernel.org/git/20241219-b4-pks-git-version-via-environment-v1-0-9393af058240@pks.im/ > > [3] https://lore.kernel.org/git/20241220-b4-pks-git-version-via-environment-v3-0-1fd79b52a5fb@pks.im/ > > [4] v2.48.0-rc0-38-gff795a5c5e Thanks. [2][3] are something we have to have before we can tag 2.48 to have a healthy build with the usual Makefile; so is a working Asciidoctor based documentation generation, so building your doc toolchain fixes on top of the fixes for 'GIT-VERSION-GEN' does not give us any practical problem. Thanks for a fix. Will queue. > > Martin > > Martin Ågren (3): > asciidoctor-extensions.rb.in: delete existing <refmiscinfo/> > asciidoctor-extensions.rb.in: add missing word > asciidoctor-extensions.rb.in: inject GIT_DATE > > Documentation/asciidoctor-extensions.rb.in | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-)
On Fri, Dec 20, 2024 at 06:42:21PM -0800, Junio C Hamano wrote: > Martin Ågren <martin.agren@gmail.com> writes: > > > The Asciidoctor build of the documentation regressed a bit with > > a38edab7c8 (Makefile: generate doc versions via GIT-VERSION-GEN, > > 2024-12-06). > > > > I think these issues and fixes are fairly orthogonal to the recent > > discussions beginning at [1], with fixes being discussed beginning at > > [2]. I've tested these here patches on top of that series' v1 [2] > > rebased onto a38edab7c8, as well as on top of its recent v3 [3] as > > applied on the indicated base-commit. > > > > With these patches, I can use > > > > make USE_ASCIIDOCTOR=YesPlease doc > > > > and > > > > ./doc-diff --asciidoctor <...> <...> > > > > with similar results as pre-a38edab7c8. > > > > On top of current master [4], these patches help, but for "doc-diff", > > the GIT_VERSION injection is still broken (as expected, that's why > > [1,2,3] exist). These here patches don't refer to doc-diff or those > > other patches [2,3] and could go in independently or on top. > > > > These patches are based on [3] applied on its indicated base-commit. > > > > [1] https://lore.kernel.org/git/20241218113324.GA594795@coredump.intra.peff.net/ > > > > [2] https://lore.kernel.org/git/20241219-b4-pks-git-version-via-environment-v1-0-9393af058240@pks.im/ > > > > [3] https://lore.kernel.org/git/20241220-b4-pks-git-version-via-environment-v3-0-1fd79b52a5fb@pks.im/ > > > > [4] v2.48.0-rc0-38-gff795a5c5e > > Thanks. [2][3] are something we have to have before we can tag 2.48 > to have a healthy build with the usual Makefile; so is a working > Asciidoctor based documentation generation, so building your doc > toolchain fixes on top of the fixes for 'GIT-VERSION-GEN' does not > give us any practical problem. > > Thanks for a fix. Will queue. Thanks indeed, the changes look good to me. I guess my key learning is to do largish patch series like the build refactorings in smaller increments next time. I considered doing it several times while implementing the series, but shied away from it. I guess it would have been easier for everyone involved and would have led to fewer issues though if I did split it up. So thanks to all the people that are helping out in this context! Patrick
Patrick Steinhardt <ps@pks.im> writes: >> Thanks. [2][3] are something we have to have before we can tag 2.48 >> to have a healthy build with the usual Makefile; so is a working >> Asciidoctor based documentation generation, so building your doc >> toolchain fixes on top of the fixes for 'GIT-VERSION-GEN' does not >> give us any practical problem. >> >> Thanks for a fix. Will queue. > > Thanks indeed, the changes look good to me. > > I guess my key learning is to do largish patch series like the build > refactorings in smaller increments next time. I considered doing it > several times while implementing the series, but shied away from it. I > guess it would have been easier for everyone involved and would have led > to fewer issues though if I did split it up. FWIW, from the project maintainer's point of view, the trickling rate of all of your series was not overly too fast. As long as the reactions to problems discovered can keep up with the same rate, I do not share the "smaller increments as we did too much too fast" sentiment myself. If you are referring to the fact that you have to scramble and fix the reported breakages on multiple fronts quickly near the end of year holiday season to keep the release candidate healthy, and regretting that we went a little too fast, then yeah, I can understand it and we may want to pace ourselves the next time to lessen the stress on all of us a bit ;-) > So thanks to all the people that are helping out in this context! Yes, big thanks to everybody.