DocBook v2

[Richard Kimberly Heck]

On 8/31/20 6:27 PM, Scott Kostyshak wrote:
> On Mon, Aug 31, 2020 at 10:52:54PM +0200, Pavel Sanda wrote:
>
>> If I see similar changes in the code I can check again, but I still
>> think that having the codebase for others in master is at the moment
>> more valuable than clean docbook tests, which might not be even correct
>> from the perspective of the second rewrite.
> That's a fair point. If we run the ctests on the branch and only see
> regressions in the docbook exports, I would be OK with merging. 

Good!


> I would still disagree with merging, because I think it makes sense to fix those
> regressions on the branch before merging and before others take a deep
> look at the code, and before other test it. 

I'm less than sure that the DocBook export we have in stable is really
correct. I think that's part of what got Thibaut working on this: Our
export *isn't* right for current flavors of DocBook. So some of the
regressions may well be fixes.

That Additional.lyx now exports with only two validation errors is
pretty amazing, I think. That's a VERY complex document.


> In my opinion, the point of
> other people testing the code and reviewing the code is to find problems
> that the author does not know about. 

Of course.


> Also, the fixes to regressions
> might be invasive, so why not just fix them before having a big review
> instead of having multiple rounds of reviews and testing and fixes on
> master? 

I think this depends upon what the regression is exactly. Of course,
that can be determined by looking carefully at the test results. But
it's a different question when it's time to do that. I'd let the code
settle, and then when Thibaut thinks we're ready to merge, *then* we
should start running tests and look carefully at the results.


> Further, even if only the docbook tests are failing, the
> underlying regressions could affect other parts of the LyX code (our
> ctests have only small coverage in my opinion). 

Assuming Thibaut is only touching DocBook-related routines, it's
probably only XHTML export that would be affected. Which matters, but,
as I said, much of this may be an improvement.

Riki