Proposed F19 Feature: Apache OpenOffice

[James Hogarth]

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130206/20a171e3/attachment-0001.html>