Comment 20 for bug 1595358

I've spent quite some time reviewing this proposed update for 16.04. This is a "soft reject" from me, pending further discussion if you'd like to address any of the comments I've made below. If there is no further discussion, I'll reject this upload from the queue when I next come past.

I appreciate the value of bumping LyX up to an upstream stable maintenance release. However, I am concerned that there doesn't seem to be enough quality assurance here to ensure that existing, happy LyX users using the packaging from 16.04 are not regressed.

16.04 has been out for three years now, and I see only a handful of bugs reported against this package since then that are still open. On balance, I question whether there's value in issuing this update wholesale now, given that most users will be moving over to 18.04 before long. I could be swayed if there appeared to be a significant number of Ubuntu users needing this update, but I don't see that. An alternative approach is to address specific fixes aimed at bugs Ubuntu 16.04 users are actually experiencing using our regular SRU process. It looks like these would be fairly easy cherry-pickable from upstream VCS and we could have far more confidence in individual testing to reduce regression risk to unaffected Ubuntu users.

Specifically:

The lyx2lyx update is presumably for the headline "ability to read and write files in the 2.2.x format" but this also appears to have no tests and landed upstream as unannotated megacommits.

As far as I can see, only four tests run during the package build.

The bugfixes in the 2.1 branch relevant to this update do not appear to come with regression tests.

The embedded version of Boost is bumped with no explanation as to why this is needed, which I find concerning because that seems counter to the idea of minimising regression risk. The use of --without-included-boost may mitigate this but needs checking that it works. Changes relating to the newer version of Boost have been made upstream, but if --without-included-boost is working, then they will apply to the build in Ubuntu without the Boost being built against having been updated.

In general, there seem to be a fairly large number of changes made upstream with little verification possible except with manual testing. I'm not sure we should be throwing these at existing Ubuntu LyX users without actually doing that testing. Accordingly, with the information I have my (quite subjective) opinion is that our regular cherry-picking SRU process would be more appropriate here.