Hi Don, Am 12.03.23 um 21:18 schrieb Don Lewis: > On 12 Mar, Matthias Seidel wrote: >> Hi Don, >> >> thank you for your detailed report! >> >> Most of the technical things are above my understanding. ;-) > Some of it is beyond mine, in particular the iterator stuff. I'm also very > unfamiliar with that part of the code and have no idea how to test it > properly. > >> But what I saw in the 4.1.14 development process was, that we have a big >> amount of code changes in trunk/AOO42X, that never got backported/released. > Yes. The code and build framework in trunk/AOO42X is much better than > AOO41X. > >> Normally, we should release it with AOO 4.2.0, but since that process is >> stagnating over years I would prefer to cherry-pick code into AOO41X >> (where possible). >> >> I already made some commits (mostly optical changes): >> >> https://github.com/apache/openoffice/compare/AOO4114-GA...AOO41X >> >> And maybe we can get AOO42X in a stable condition in parallel? > Trying to cherry-pick a lot of this stuff back into AOO41X would be a > lot of work. There are a lot of commits that would need to be > inventoried. There are also a lot of interdependencies, so the > cherry-picks would have to be done in the right order. Then there would > still likely be a bunch of merge conflicts that would need manual > intervention to resolve, with thie possibility of introducing bugs.
That's why I wrote "where possible". Fact is that we need to have a branch available that can be released when needed. As long as we are able to release AOO42X. > > I see this as putting a lot of effort into something that is ultimately > a dead end. I think it would be better in the long run to get 4.2.0 out > the door. In Germany we say: "You run against open doors" ;-) If I only could be of help here... But the work on AOO42X should really be intensified. > > Something else that should be higher on the priority list is migrating > to a more modern Windows toolchain that has support for modern C. We > spent too much effort on working around the limitations of our current > Windows compiler when importing new versions of bundled third-party > code. Definitely! I think moving to a newer compiler is the first step we need to do on Windows. Again, I can not be of great help here but I will try to build everything that we have. Regards, Matthias > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org >
smime.p7s
Description: S/MIME Cryptographic Signature
