Hi jim, all
I have written quite a lot. I hope it intrigues a lot of people to voice
their opinions. Every opinion is welcome.
Main topic is next steps for AOO5, that start at the first dash line below.
Am 20.10.2026 um 12:30 schrieb Jim Jagielski:
Sorry... Your reply didn't sound like a proposal but rather a command, but I
now understand that that was not your intent. I am still a firm believer that
it is the _intent_ that matters and, as Archimedes in `The Once And Future
King` says:
"...I bitterly regret that I should have been so petty as to take offense where none
was intended."
Hmm, I think you are not wrong that I chose a imperative wording. We do
not have many decided things. The buglist for former 4.2 now 5, was one
of the view things that is imperative on my list to work down.
I have heard Matthias complains so many time that there is no progress
towards a 4.2 release, that for me this is a command to work down.
There is a cwiki side which did not work, and we had the bug list where
no one looks onto. So for me it is somewhat imperative that this list is
the one that we should focus on. That maybe caused the harsh tone on my
side.
I hope i can frame things better in future. And while i totally want
this list, the content is open for discussion. And i do not mind if we
make a wiki page. Just don't expect me to be the first volunteer to work
with the cwiki. I would rather like to try use bugzilla.
I have enough retro on this. Lets focus on next steps again.
-------------------------------------------------------------------------------
Dave suggested that Jim's intend was to do a planing High level. So I
would like to pick that up, too.
** the code **
The current situation is that that I think trunk has one or two
regressions. One is windows specific. A Version number has to many 0, so
the installer crashes. I have the fix, but I am lost in to many topics
to commit it. I want to but failed so far. Please bear with me.
There is IMHO a Ceszlaw crash find, that needs to be looked at. But i am
not sure anymore if that is fixed or not.
Then we have a view left blockers left on the list, some are 4.2
regressions. We need to review and fix. This is top on my list, just
after ICU (see below)
If those are solved, IMHO we should be close to a delivery. Unless mac
or linux pop something up. I think we have lest tests on those systems.
I would say that is the mandatory part. In general we are in good alpha
maybe even beta state.
----
* other bugs *
The 4.2 list sported some more issues, which always were considered for
4.2. I think they are not essential, but by history. They don't have a
theme or vision, so i would handle them as such.
I see those as discussion worthy. we can scope them or defer / delay them.
* translation pipeline *
In order to be able to translate AOO, we need a round trip.
1) AOO during build we need to extract the English text components and
store this into sdf file format.
2) the sdf definition files need to be converted into pootle format.
3) the pootle files need to be imported into our translation web
environment.
4) translators do their thing.
5) we pull the data from the translation web environment, and put it in
pootle files
6) conversion of the pootle files into sdf.
7) Package the sdf files with AOO
now the roundtrip is broken in multiple parts.
1) conversion does not work or is not smooth / error prone enough to
handle that.
Currently we have a script bundle that does the process but we never
managed to put on a true ci/cd.
2) for extraction on a ci/cd bases we need a working build bot.
3) we need to update the translation web environment.
Side node. No body translates anything at the moment, maybe it kicks
back in when we have something that just works. unknown. (I don't have
first hand info, only Matthias status talk)
Now how we do this is not decided, I wanted to do the translation part
on github actions, but i changed my mind. My current idea is to add the
ability into the build environment. That would remove the requirement to
handle sdf file on our translation repo. we could work there only in
pootle. reduced complexity. and easy to use.
Draw back is that build times would grow.
the transition from pootle (current translation environment) to weblate
seemed smooth. I made some first test but could not finish. an image
setup is really easy.
** Dependencies **
I added 2 dependency issues i found in the backlog.
- icu
- expat (thanks jim for looking into it.
I analyzed all windows concerning ones.
Most dependencies we are one or two miner versions behind.
The question is do we want to scope all or move some.
My preference is to update only a MVP set. And the obvious candidate is ICU.
I am currently testing the integration with the latest version. I back
ported already all changes we might want in the old base.
What is left is testing if dictionaries still work, and on Linux adding
harfbuzz. So expect the commit shortly.
(I added encoding translation of encodings we do not support but ICU,
reintroducing support to some encodings that we had to drop because of
licensing issues. But not tested yet.)
* OS API support *
i see this a bit separated from the dependency topic. I have build
knowledge on windows, and only little for Mac OS.
Currently windows changed nothing, Linux if i noted that correctly has
more issue fixes no modernization. Mac i don't know.
We could defer the modernization. For windows this would mean there are
no issues to allow win 7. because win 7 is fully supported on latest MS
compilers.
GTK2 / 3 i dont know the exact situation, but i guess it is working fine
too. same with Mac.
For windows i would like to defer modernization, despite i already
started to work on it. I have a patch for 4k, multi monitor support. But
IMHO this is incredibly difficult to do in small steps, you quickly
start looking at things and bugs, or quirky behavior.
I would like to fix some other parts first before continuing on Windows
modernization. I have some ideas too, i want to test and would love to
have more time for that. The GUI seems to work well enough as is.
* ODF *
I keep forgetting this topic. We are done i think on the odf 1.3 gap
analysis and need to continue on 1.4.
We could define that as a requirement or not. Personally I think it
would be a strong public move if we could update to 1.4.
I have done some analysis bout our support on 1.2 and AI claims a view
issues, but have not managed to look deeper.
*extension support *
As you all know our extension website is frozen. no changes can be made
easily. That means extensions for V5 are not supported.
now a dictionary is needed and we pull that through our extension
webpage if i got that correctly. At least i am not able to find them in git.
AOO without dictionaries is a huge hit. And AFAIK we lost here all or
most of the supporters that maintained the ones.
We have 2 obvious choices (happy to hear more)
1) fix the extension site. (5gb HTML site. We don't need all pages, but
still you need to do it programmatically.)
I started the work but it is its infantile state.
2) we make sure we are compatible with LO and point AOO5 users to the
TDF extension page.
Not all will work. but maybe we can deliver patches to the extensions
where we are incompatible, because they tap into our internal code that
differs from LO.
Risky but maybe less infra work for us. (maybe the idea is stupid, it is
not well thought on my side.
* repo extensions *
we have some extensions in the repo.
1) pdf importer
- have a working update based on Apache pdfbox. needs working java. I
plan to switch to a different lib, i don't have the name now, that
eliminates java requirement.
both would eliminate the license x rate embargo the code currently have.
2) wiki-writer
I did not find the time for a closer look, but this has at least 2 very
old dependencies we must fix. one is tomcat 5!
3) ole windows integration.
that needs a ms dll, only present in professional build environments. I
found one, now lurking on my disk.
what the code does is to integrate AOO in windows ole infrastructure,
which allows it then to talk to ole apps.
I think this is maybe nice to have, but not mandatory for us.
I think this are the topic where we should think we should look at to
define on the ready state of AOO5.
MVP would be for me mandatory code fixes, maybe manual translation
pipeline, vital dependency pushes.
So that is what i would see as topics in a scope discussion, and we can
draw the line where ever we want. The more we scope the longer it takes.
I would like to sport a AOO5 release in 2027 Q1, if possible January.
And i would like to tailor the scope to this goal, but i am open for
other ideas.
On Oct 19, 2026, at 3:58 PM, [email protected] wrote:
Am 19.10.2026 um 21:41 schrieb [email protected] <mailto:[email protected]>:
Am 19.10.2026 um 21:11 schrieb Jim Jagielski:
The search named 5.0.0 OpenIssues does not exist.
I've got a smashing idea... let's pick a method that works for _everyone_...
you know, let's work as a _team_ and _compromise_ and universally agree to a
method.
Are you saying that you are not able to handle Bugzilla?
I am sorry. I overstepped here.
I do try to get everyone into the same boat. I have prepared the list, and
wrote about the work to.
And it feels offending to me if you imply that I do not try to work together. I
snatched here.
I would like to ask you to assume that we all want to work together and
consider a counter proposal when one is offered. Even if it is not done in the
best way.
Thanks.
All the best
Peter
All you need to do is to set up a search to filter on target milestone 5.0.0
It should return 37 issues.
In the meantime i figure out how to share search lists.
On Oct 19, 2026, at 3:05 PM, [email protected] wrote:
Am 19.10.2026 um 18:56 schrieb Jim Jagielski:
Can we maybe use this wiki page to coordinate work on AOO5:
https://s.apache.org/AOO5-TODO
I dont like to maintain a confluence page.
https://bz.apache.org/ooo/buglist.cgi?cmdtype=runnamed&list_id=253306&namedcmd=5.0.0%20OpenIssues
Not sure if the list can be seen by others, but this is my reference list.
There is a list for 4.2.0 in confluence with almost same issues open.
TIA
On Oct 19, 2026, at 7:08 AM, Jim Jagielski <[email protected]> wrote:
Thanks for the Email! Your timing is perfect.
Right now, the main effort is working on getting `trunk`, and specifically the
`AOO50X` branch to a relative stable place where we could do a Developer's
Release; let's work on stuff that has an immediate positive impact and gets us
closer to a release. So things like checking if AOO50X builds for you, if it
works and where it doesn't. Things like that.
Sure, it would be great to rip-out our current build structure for something
"modern", for example, but focusing on that improves where are _are_ and
doesn't move us forward, if you get my meaning. It's a lot of work that ends up with us
being at the exact spot where we are now. In fact, it actually means we step back because
now this whole new build system needs a lot more testing before we can ensure parity with
what we already have. I am simply using the build system as a convenient example, nothing
more, btw.
AOO50X uses a newer version of C++ and baselines Python 3, so those are other
good things to check.
On Oct 19, 2026, at 6:00 AM, Gaurav <[email protected]> wrote:
Hi everyone,
I'm Gaurav, a master's student in Applied Data Science at USC (Los
Angeles). I work primarily in C++ and Python, and I'd like to volunteer
with OpenOffice.
To start, I'm happy to help with bug reproduction and triage, or small C++
bug fixes — whatever is most useful. I've gone through the New Volunteer
Orientation modules [only say this if you actually do].
Could someone point me to where help is most needed right now, or a good
first bug to look at?
Thanks,
Gaurav Nagalapuram Venkataramanan
--
Jim
"This is an outrage!"
Tony Harrison
--
Jim
"This is an outrage!"
Tony Harrison
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
--
Jim
"This is an outrage!"
Tony Harrison
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
--
Jim
"We are havin' it large!"
Tony Harrison
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
