Hi Damjan, Am 30.03.19 um 11:09 schrieb Damjan Jovanovic: > >From my email on 15 February 2019: > > My own release checklist would include: > 1. Library audit. > 1.1 Did we lose or gain any public symbols in our libraries since the > 4.1.0? Gbuild requires explicit export instead of exporting everything and > then possibly controlling visibility with a .map file, so it's very > possible. > 1.2 Did ELF symbol versions on *nix platforms change? The older gbuild > modules probably did, as I didn't understand the meaning of .map files back > then. > 1.3 Are the same libraries with the same names available in both 4.1.0 and > 4.2.0? > 2. Base: > 2.1 Complete the Java SDBC driver framework, used by both the new SDBC-JDBC > bridge and the Postgres SDBC driver. > 2.2 Audit the new SDBC-JDBC bridge in Java against the old C++ one, fix any > differences. > 2.3 Complete the Postgres SDBC driver; still needs views, users, groups, > etc. > 2.4 Complete the integration of the Postgres SDBC driver into the Base UI > forms (like MySQL already is). > 3. Crashreporter > 3.1 Get it working again. > 3.2 Bug reported in UI form (instead of submitted to some now obsolete > server), which can be copied/pasted or attached to Bugzilla. > 4. Testing > 4.1 Run all available tests (unit tests, smoketest, module integration > tests, bvt, fvt, etc.) against 4.1.0 and 4.2.0, find and fix any > regressions. > > --- > > So far, my library audit revealed a lot of symbol changes in some modules > and a more detailed examination is necessary. Need to study ELF further to > understand symbol versioning better. Also the GetVersionInfo symbol in UNO > components is consistently missing when they are built by gbuild; dmake got > it in by linking main/solenv/src/version.c into every library somehow, and > gbuild should do the same. > > I've started some work on the Base stuff. To understand it better and get > IDEs to play with it better, I am currently porting main/connectivity to > gbuild. Still need to develop gbuild infrastructure to handle processing > XCU/XCS configuration files with XSLT scripts, but many other modules need > that too.
Thanks for all your work! It is highly appreciated. Unfortunately all this is high above what I understand but I am confident that other members will join the effort. > > Crashreporter involves complex interaction between code in main/sal and > main/crashreporter, multiple files get generated and passed around. It > shouldn't be too hard to get working though. While I'd like to see crashreporter functional again in 4.2.X it must not necessarily be in 4.2.0 but could come with a later (micro) release (my opinion). But the sooner the better. > > Nothing done regarding testing yet. Apart from the automatic tests I want to add 3 major tasks: 1. QA 2. QA 3. QA ;-) Regards, Matthias > > Damjan > > > On Sat, Mar 30, 2019 at 11:32 AM Stehmann <o...@mechtilde.de> wrote: > >> Hello >> >> Am 29. März 2019 19:40:47 MEZ schrieb Damjan Jovanovic <dam...@apache.org >>> : >>> I have a lot of experience with desktop integration but am too busy to >>> have >>> a look. >>> >>> Also I posted a checklist of things we should do for the release. None >>> of >>> them are done yet. >> Can you please post the list again >> >> Mechtilde >>> >>> >>> On Fri, Mar 29, 2019 at 1:23 PM Jim Jagielski <j...@jagunet.com> wrote: >>> >>>> Does the lack of desktop integration in m1 mean that this dev release >>> is >>>> DOA? >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>>> >>>> >> -- >> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. >> >> --------------------------------------------------------------------- >> 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