On 24 May 2013 13:30, Justin Ross <justin.r...@gmail.com> wrote: > Some of the issues you raise will be addressed in an upcoming "update" > mail, so I won't address them here. > > On Sun, May 19, 2013 at 9:00 PM, Robbie Gemmell > <robbie.gemm...@gmail.com> wrote: >
[.. snip ..] > > I had a quick look at the source and had a couple of questions: > > > > Am I right in thinking you now need to perform 2 generation steps to get > > from the docbook source to having output that can be put up on the site? > > This seems a little cumbersome, especially given the current single > > generation step seems to make people too lazy to publish their changes on > > the site as it is (though I guess we should just get around to automating > > this with a build on the ASF Buildbot instances and link to that). > > Sort of. In general, for release content, there's a special > generation step. That's really a per-release task, however, not > something that many developers would typically do. The idea is that > the release manager would do the generation with each new release. > I've spent a good deal of time to make this easy (much easier than > it's been in the past), probably because it's one of the jobs I've had > to do with each release. > > Also, I guess I should say that the two steps are easily collapsed: > "make gen-release RELEASE=0.22 render". > > Trunk documentation would, as you suggest, best be solved by automated > builds. > > So I'm at a bit of a loss as to why a two step document generation process would be a good idea. Is there something that is now being done that cannot be done using the docbook -> html XSL transforms? I'm not the greatest fan of docbook, but adding in a secondary transform on top of an existing transform seems a little odd. If docbook cannot give us the output we need, why are we still using docbook? -- Rob
