>
> Apache OpenOffice 4.0, due in the last decade of July 2013, is a major update.
> The two new versions (3.4.0 and 3.4.1) released in 2012 under the Apache
> guidance totalled 60 million downloads so far, not counting mirrors.
>

This should probably be fixed to due at the end of July 2013 or something similar.

> Packaging is the main issue here. The default OpenOffice build process produces
> RPM packages, but there are major changes to be done to obtain a set of RPM
> packages and matching SRPMs suitable for inclusion in Fedora.
>
> Version 4.0 produces packages based on the current product name: this allows
> to avoid name clashes with older versions of OpenOffice.
>
> The OpenOffice sources have been updated to allow a clean build with the default
> tools shipped with Fedora 19.
>

Has it been built cl cleanly in rawhide and koji yet? It'd be nice to include the package review bugzilla ticket for a 'new' package too...

> The change is isolated, except some possible packaging overlap with LibreOffice,

Has this been actually resolved with the LO maintainers yet? I recall fairly well the previous discussion but I don't think it was actually resolved...

>
> Other developers:
> This issue was widely discussed for Fedora 19 too (the feature was then
> postponed to Fedora 20 since OpenOffice 4.0 was rescheduled to be released after
> Fedora 19).
>

F20 branch is provisionally august 6th... Last time round it wasn't just the GA date of AOO that was a concern but also any knock on effect in LO as I recall... Are the timelines for package review and so on saner this time?

> The /usr/bin/soffice and /usr/bin/unopkg executables/symlinks are still a
> problem since (in the Fedora packages) they would conflict between LibreOffice
> and Apache OpenOffice: it is recommended to fix it in the LibreOffice packages too.

Have the LO maintainers agreed on this yet?

> upstream LibreOffice packages do not rely on a "soffice" symlink.
>

As I recall the concern ended up not being LO itself but third party scripts relying on soffice and breaking those... In addition if behaviour of the two 'owners' of soffice changes when it is called then what should the accepted consequence be?

> Anyway, some coordination will be needed, as already envisaged by FESCo for
> Fedora 19, to ensure a smooth user experience.

Like last time round there are s specific areas that still concern me... Which would have been much relieved if work had been done since last time round in rawhide to resolve those issues... Are any issues likely to versions prior to branch?

Personally I think the LO maintainers need to weigh in and if there are any concerns from that direction push back to F21 with work done on rawhide after branch...