There are some critical differences here. Especially, if I understood correctly the discussion we had at FOSDEM, the fact that OpenOffice is not going to be on install media or in the default package selection allows for some flexibility with respect to deadlines.


Except that the proposals you have in place including modifying LO install behaviour to allow for the existence of AOO  which *is* on installation media plus in default package selections and that knock on effect should not be dismissed.


What the proposal is meant to ensure is that Fedora 19 users will be able to install OpenOffice 4 from the official Fedora repositories and without experiencing any conflicts with other packages. It seems clear from the current discussion that some preparation work is needed, especially concerning the LibreOffice packaging, so this needs to be addressed before Fedora 19 is released.

If it helps to package 3.4.1 as an intermediate step, fine. This will still allow us to clarify issues and fix packaging conflicts. But we will then want to package 4.0 as soon as it is released as stable. I thought that the policy would forbid such upgrades but (again at FOSDEM) I got feedback that this is up to the packagers too. Anyway, if this plan accommodates concerns about packaging pre-release software, I could be OK with it.



And I don't see a gain to do that work in the F19 branch and have this labelled as a F19 feature... work on it in rawhide after the branch and if all goes well request builds be made for F19 at the appropriate time (as indeed MariaDB builds have been built for F17/18 now that the packages are 'stable' to assist with testing prior to the F19 switch over).


OpenOffice has three wikis and a lot of outdated content. Just rely on the link in the proposal. The page you mention won't get updated.


Unless this is cleared up I see this as a negative towards having AOO in Fedora. If a user gets this by some means and then searches for information they are going to get a lot of incorrect, misleading and confusing results from what appear to be official sources...


OpenOffice 4 will be released when it's ready. That's it. April 2013 is an estimate to have a timeframe for collateral activities (such as logo design), but the project will use more time if needed and reasonable. I know this doesn't fit well with a time-based distribution release policy, but the project won't release as stable something that has not been tested enough. Some parts, for example the accessibility work, have made much more progress than what we expected; but for some it's still hard to have anything more than a tentative deadline.

(As for your suggestion, I needn't check with companies or individuals what their schedule is: I'm up-to-date with the current progress.)


IBM appear to be the primary drivers at present and are the only ones who can vet/relicense the Symphony code which appears to be a key part of 4.0 which I why I suggest clarification on various pieces of work and expected timelines be made with them - given a lack of info from other public sources.

With a timeline that vague and so close to expected F19 release potentially it again leads concern to trying to rush this into F19 rather than taking a more careful approach in rawhide to iron out issues without causing problems to users in the 'stable' release. 
 
I noticed itinstalled to /opt which is an immediate violation
of the packaging guidelines

What we are looking at is the 3.3.0 spec file (F14). Packaging will be based on that (and perhaps on the LibreOffice spec file), and not on the RPMs available from the OpenOffice site.


Using the spec back then (august 2010) or the LO spec as a starting point is viable but would need to be validated against current packaging guidelines (for the former) and would still need a lot of work to it in order to resolve the conflicts with LO in either case... If we are assuming we aren't using the existing RPMs at all then there exist zero RPMs currently in rawhide prior to branch... it would seem a very tight timeline for packages that haven't been looked at much in two years...

With the changes that would be needed to LO too (and the discussion yet to be had about soffice, oowrite, oocalc and so on) it would seem to be safer to carry out these trials in rawhide first and not consider this as something 'for F19' as it were.