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
>>
>>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to