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
