Jaroslav Reznik wrote:
= Features/ApacheOpenOffice = https://fedoraproject.org/wiki/Features/ApacheOpenOffice
Feature owner(s): Andrea Pescetti pescetti@apache.org
Add Apache OpenOffice, the free productivity suite, to Fedora.
A big -1 to this feature, and in fact I'd urge FESCo to veto that package outright (or if it somehow already made it into Fedora, to get it blocked in Koji and Obsoleted by libreoffice ASAP).
Rationale: * What benefit does this package have over LibreOffice, to justify carrying 2 packages doing essentially the same thing? * OpenOffice is a huge package and a big strain on our build system (Koji); IMHO, having 2 versions of it would be a gigantic waste of resources. * LibreOffice is clearly the community version to be preferred: - All major distros support it. - Red Hat people work on it. - AFAIK, it has more features. whereas Apache OpenOffice is the fork Oracle created to remove control over the project from the community, after Oracle had refused for months to cooperate with the community (and for those months, LibreOffice had been the only version being developed at all). (I consider it a big mistake on the part of Apache to have accepted that trojan horse "donation". They should have pointed Oracle to the existing LibreOffice project instead. I really don't see why OpenOffice.org had to be donated to Apache when basically all the existing non-Oracle developers were involved in LibreOffice instead and when all that was needed was assigning the OpenOffice trademark to them.)
PS: I wonder if there's any connection between this feature and the MariaDB feature (or rather, Oracle's negative response to it).
Kevin Kofler
PPS: Oh, and this:
The /usr/bin/soffice alias is still a problem since (in the Fedora packages) it would conflict between LibreOffice and Apache OpenOffice: it is recommended to fix it in the LibreOffice packages too, at least using the Alternatives system.
is just not acceptable. Alternatives is the wrong solution for this (in fact, I'd argue it's always the wrong solution), because it is systemwide. Why can't you just rename or delete /usr/bin/soffice?
Kevin Kofler
On Mon, 04 Feb 2013 08:35:43 +0100 Kevin Kofler wrote:
PPS: Oh, and this:
The /usr/bin/soffice alias is still a problem since (in the Fedora packages) it would conflict between LibreOffice and Apache OpenOffice: it is recommended to fix it in the LibreOffice packages too, at least using the Alternatives system.
is just not acceptable. Alternatives is the wrong solution for this (in fact, I'd argue it's always the wrong solution), because it is systemwide. Why can't you just rename or delete /usr/bin/soffice?
+1 from me as well. Having alternatives for this is just bad. Either you're saying you're packaging something different -- then alternatives is out of question -- or you're packaging something that is 1:1 interchangeable, but than I don't see a reason to actually ship both.
I disagree with your previous mail though (even though I don't necessarily disagree with your reasoning against - i.e. "waste" of resources *is* a strong argument). While AOO and LO started from the same point, they're not doing the same *and* in the future you can expect further divergence. Fedora has always been the one to bring new things first, we should do so, IMHO, in this case as well.
Also, going by your reasoning there would be no point in having Calligra either... Furthermore, technically LO is the fork ;-)
I don't think Oracle has anything to do with it any more, they just got rid of unwanted "spoils of war". Although, I might be wrong.
Martin
On 04/02/13 13:59, Martin Sourada wrote:
Also, going by your reasoning there would be no point in having Calligra either... Furthermore, technically LO is the fork ;-)
technically, both Apache OpenOffice and LibreOffice are forks, since neither of them:
a) are under the OpenOffice.org governance scheme b) are developed under the processes that OpenOffice.org used c) require a copyright assignment to Sun/Oracle to contribute d) license the code under LGPLv3 as OpenOffice.org always was [this is technically still true for LibreOffice but will change] e) are developed by the Sun/Oracle staff that have always done the majority of the programming on OpenOffice.org in its time f) run on the infrastructure in Sun/Oracle's Hamburg lab
04.02.2013 10:47, Kevin Kofler wrote:
Jaroslav Reznik wrote:
= Features/ApacheOpenOffice = https://fedoraproject.org/wiki/Features/ApacheOpenOffice
Feature owner(s): Andrea Pescetti pescetti@apache.org
Add Apache OpenOffice, the free productivity suite, to Fedora.
A big -1 to this feature, and in fact I'd urge FESCo to veto that package outright (or if it somehow already made it into Fedora, to get it blocked in Koji and Obsoleted by libreoffice ASAP).
Rationale:
- What benefit does this package have over LibreOffice, to justify carrying 2 packages doing essentially the same thing?
- OpenOffice is a huge package and a big strain on our build system (Koji); IMHO, having 2 versions of it would be a gigantic waste of resources.
- LibreOffice is clearly the community version to be preferred:
- All major distros support it.
- Red Hat people work on it.
- AFAIK, it has more features.
Does anyone have or known real table of differences of futures? I think it may be important see there.
2013/2/4 Kevin Kofler kevin.kofler@chello.at
Jaroslav Reznik wrote:
= Features/ApacheOpenOffice = https://fedoraproject.org/wiki/Features/ApacheOpenOffice
Feature owner(s): Andrea Pescetti pescetti@apache.org
Add Apache OpenOffice, the free productivity suite, to Fedora.
A big -1 to this feature, and in fact I'd urge FESCo to veto that package outright (or if it somehow already made it into Fedora, to get it blocked in Koji and Obsoleted by libreoffice ASAP).
Rationale:
- What benefit does this package have over LibreOffice, to justify carrying 2 packages doing essentially the same thing?
- OpenOffice is a huge package and a big strain on our build system (Koji); IMHO, having 2 versions of it would be a gigantic waste of resources.
- LibreOffice is clearly the community version to be preferred:
whereas Apache OpenOffice is the fork Oracle created to remove control over the project from the community, after Oracle had refused for months to cooperate with the community (and for those months, LibreOffice had been the only version being developed at all). (I consider it a big mistake on the part of Apache to have accepted that trojan horse "donation". They should have pointed Oracle to the existing LibreOffice project instead. I really don't see why OpenOffice.org had to be donated to Apache when basically all the existing non-Oracle developers were involved in LibreOffice instead and when all that was needed was
- All major distros support it.
- Red Hat people work on it.
- AFAIK, it has more features.
assigning the OpenOffice trademark to them.)
PS: I wonder if there's any connection between this feature and the MariaDB feature (or rather, Oracle's negative response to it).
Kevin Kofler
I completely agree!
Kevin Kofler wrote:
- What benefit does this package have over LibreOffice, to justify carrying 2 packages doing essentially the same thing?
They are indeed two productivity suites, but they are evolving in different directions. There's a "Features" link in the proposal https://fedoraproject.org/wiki/Features/ApacheOpenOffice that lists unique features of OpenOffice 4.0, including the new user interface (sidebar), the new accessibility support (a key factor for adoption by institutions), interoperability enhancements and performance improvements. Again, the proposal is not saying or implying in any way which of the two is better, and this might vary by user, or even by single task.
- OpenOffice is a huge package and a big strain on our build system (Koji); IMHO, having 2 versions of it would be a gigantic waste of resources.
This might be a legitimate technical concern. Honestly I didn't think that OpenOffice could be too big for Fedora, but I didn't see any limitations in the Fedora guidelines.
- [...] Apache OpenOffice is the fork Oracle created to remove control over the project from the community
These are opinions and belong to the past anyway. Again, this is not an educational thread about Apache OpenOffice; but a quick look at the current OpenOffice website http://www.openoffice.org/, blog http://blogs.apache.org/OOo/ and mailing lists http://openoffice.apache.org/mailing-lists.html is enough to understand that OpenOffice is an actively developed product managed by an active community (and also that the community is open, welcoming and very collaborative with other projects, even though these factors may count less in the current discussion).
PS: I wonder if there's any connection between this feature and the MariaDB feature (or rather, Oracle's negative response to it).
No connection at all. But anybody who can even think of this possibility should really get some up-to-date information about OpenOffice: the Apache graduation process isn't easy, and there is a huge difference between the project that graduated as an Apache Top-Level Project in October 2012 and the project that started incubation at Apache in June 2011. Is it totally unconceivable that Oracle or the MariaDB feature can influence the OpenOffice project as it is today: actually, I wasn't even aware of the MariaDB discussions on this list when I posted the OpenOffice proposal.
Regards, Andrea.
On 4 February 2013 12:39, Andrea Pescetti pescetti@apache.org wrote:
Kevin Kofler wrote:
- What benefit does this package have over LibreOffice, to justify
carrying 2 packages doing essentially the same thing?
They are indeed two productivity suites, but they are evolving in different directions. There's a "Features" link in the proposal https://fedoraproject.org/**wiki/Features/ApacheOpenOfficehttps://fedoraproject.org/wiki/Features/ApacheOpenOffice that lists unique features of OpenOffice 4.0, including the new user interface (sidebar), the new accessibility support (a key factor for adoption by institutions), interoperability enhancements and performance improvements. Again, the proposal is not saying or implying in any way which of the two is better, and this might vary by user, or even by single task.
When this hit the fedora-devel mailing list it actually spurred me to look at the AOO mailing list and compare features between OO.org/AOO and LO...
The first problem here is that the "rough target for release" as it has been named is in April... the branch from rawhide is currently estimated to be end of February - AOO isn't even packaged and in rawhide yet - forget the main release - and for such a large package with the issues pointed out about conflicting names in soffice, oocalc, oowriter and so on (which has a knock on effect on LO packaging) is up for question - assuming AOO gets packaged at all.
We all know how releases can get delayed as well and as this is the first *major* release of AOO with the IBM Symphony code being merged in (with the new look and so on) it would seem logical to have a higher chance of delay or have a higher level of bugs or kinks to be worked out due to the Symphony merge ongoing rather than the older (but stable) oo.org code/UI.
So it would seem advisable to take the 4.0 release out of scope and focus on whether 3.4.1 (current) can be packaged given the issues already raised and then look at 4.0 as and when AOO complete their work.
I followed the links from your fedora proposal page to look at features...
The release planning link for 4.0 has no details as to when a beta might be available and everything is 'in progress' or 'proposed' with not much detail and fairly vague descriptions.
The 'code' link is to the branches directory of the openoffice code - but it's not clear what you intend to build/package/release from that which is perhaps not that surprising given that 4.0 doesn't even exist yet in alpha much less beta state.
The 'document fidelity' and 'sidebar' links are for proposals/work for 4.0 and given the high likelihood of not making F19 (even the proposal page acknowledges this and suggests falling back to the stable 3.4.1 code) I submit should not be used in evaluating this proposal at this time... the 4.0 page doesn't even have any test details, and the release notes are very empty:
Now taking the assumption of AOO 3.4 (which I b
Apologies for the accidental send before...
On 4 February 2013 12:39, Andrea Pescetti pescetti@apache.org wrote:
Kevin Kofler wrote:
- What benefit does this package have over LibreOffice, to justify
carrying 2 packages doing essentially the same thing?
They are indeed two productivity suites, but they are evolving in different directions. There's a "Features" link in the proposal https://fedoraproject.org/**wiki/Features/ApacheOpenOfficehttps://fedoraproject.org/wiki/Features/ApacheOpenOffice that lists unique features of OpenOffice 4.0, including the new user interface (sidebar), the new accessibility support (a key factor for adoption by institutions), interoperability enhancements and performance improvements. Again, the proposal is not saying or implying in any way which of the two is better, and this might vary by user, or even by single task.
When this hit the fedora-devel mailing list it actually spurred me to look at the AOO mailing list and compare features between OO.org/AOO and LO...
The first problem here is that the "rough target for release" as it has been named is in April... the branch from rawhide is currently estimated to be end of February - AOO isn't even packaged and in rawhide yet - forget the main release - and for such a large package with the issues pointed out about conflicting names in soffice, oocalc, oowriter and so on (which has a knock on effect on LO packaging) is up for question - assuming AOO gets packaged at all.
We all know how releases can get delayed as well and as this is the first *major* release of AOO with the IBM Symphony code being merged in (with the new look and so on) it would seem logical to have a higher chance of delay or have a higher level of bugs or kinks to be worked out due to the Symphony merge ongoing rather than the older (but stable) oo.org code/UI.
So it would seem advisable to take the 4.0 release out of scope and focus on whether 3.4.1 (current) can be packaged given the issues already raised and then look at 4.0 as and when AOO complete their work.
I followed the links from your fedora proposal page to look at features...
The release planning link for 4.0 has no details as to when a beta might be available and everything is 'in progress' or 'proposed' with not much detail and fairly vague descriptions.
The 'code' link is to the branches directory of the openoffice code - but it's not clear what you intend to build/package/release from that which is perhaps not that surprising given that 4.0 doesn't even exist yet in alpha much less beta state.
The 'document fidelity' and 'sidebar' links are for proposals/work for 4.0 and given the high likelihood of not making F19 (even the proposal page acknowledges this and suggests falling back to the stable 3.4.1 code) I submit should not be used in evaluating this proposal at this time... the 4.0 page doesn't even have any test details, and the release notes are very empty:
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
Now taking the assumption of AOO 3.4 (which I believe is sane) what does this bring over LO?
Reading the release notes of that release it looks like everything is in either the current stable LO or the LO 4.0 release which is just about to happen well ahead of a rawhide branch...
Might I suggest focusing on packaging 3.4.1 for rawhide and dealing with the issues surrounding conflicts and if that gies well consider the 4.0 release (or whatever lines up then) for F20?
On Mon, 4 Feb 2013 14:31:11 +0000 James Hogarth wrote:
Might I suggest focusing on packaging 3.4.1 for rawhide and dealing with the issues surrounding conflicts and if that gies well consider the 4.0 release (or whatever lines up then) for F20?
That's mostly how I understand the proposal. The goal for F19 is to get it in and solve (potential) conflicts. It should probably either drop the mentions of 4.0 or clearly state that 4.0 is going (unless some kind of miracle happens) in F20 and this is just preparation stage -- i.e. getting the latest stable in, working and without conflicts.
Martin
Martin Sourada wrote:
On Mon, 4 Feb 2013 14:31:11 +0000 James Hogarth wrote:
Might I suggest focusing on packaging 3.4.1 for rawhide and dealing with the issues surrounding conflicts and if that gies well consider the 4.0 release (or whatever lines up then) for F20?
That's mostly how I understand the proposal. The goal for F19 is to get it in and solve (potential) conflicts. It should probably either drop the mentions of 4.0 or clearly state that 4.0 is going (unless some kind of miracle happens) in F20 and this is just preparation stage -- i.e. getting the latest stable in, working and without conflicts.
And what would be the benefit of that way of proceeding to the user?
It seems to me that this feature needs to be punted from F19 and reevaluated for F20, after F19 branches.
Kevin Kofler
Martin Sourada wrote:
That's mostly how I understand the proposal. The goal for F19 is to get it in and solve (potential) conflicts. It should probably either drop the mentions of 4.0 or clearly state that 4.0 is going
Actually, the feedback I got at FOSDEM was to focus on packaging trunk for the time being.
But indeed, the biggest effort is on packaging in a way that it is satisfactory for everybody, and for this first step it doesn't really make a technical difference whether we use 3.4.1, a recent 4.0 milestone or 4.0, since the major infrastructural changes were already done in OpenOffice 3.4.0 and newer versions do not introduce new dependencies (although trunk uses an updated product name, that could help in solving some conflicts).
In Fedora, even installing OpenOffice manually (i.e., by downloading RPMs from the OpenOffice website) is problematic since: 1) it won't install cleanly due to the conflicting "soffice" alias 2) even if you force installation, "yum update" can wipe out OpenOffice since one of the LibreOffice RPMs obsoletes the OpenOffice RPMs.
It is surely possible to do better, and to do so in a way that leaves the user experience for LibreOffice end-users unchanged. This is what I see as a first step.
Note that I haven't had time to check with F18 yet, so I welcome feedback on this if someone can test before I do.
Regards, Andrea.
Actually, the feedback I got at FOSDEM was to focus on packaging trunk for the time being.
But indeed, the biggest effort is on packaging in a way that it is satisfactory for everybody, and for this first step it doesn't really make a technical difference whether we use 3.4.1, a recent 4.0 milestone or 4.0, since the major infrastructural changes were already done in OpenOffice 3.4.0 and newer versions do not introduce new dependencies (although trunk uses an updated product name, that could help in solving some conflicts).
In Fedora, even installing OpenOffice manually (i.e., by downloading RPMs from the OpenOffice website) is problematic since:
- it won't install cleanly due to the conflicting "soffice" alias
- even if you force installation, "yum update" can wipe out OpenOffice
since one of the LibreOffice RPMs obsoletes the OpenOffice RPMs.
It is surely possible to do better, and to do so in a way that leaves the user experience for LibreOffice end-users unchanged. This is what I see as a first step.
Note that I haven't had time to check with F18 yet, so I welcome feedback on this if someone can test before I do.
Let's take a look at a similar (although of course not identical) situation with respect to a package that is very similar to another - indeed will conflict on certain files even - and the process/time that took to get packaged...
https://bugzilla.redhat.com/show_bug.cgi?id=875150
This the the MariaDB packaging review request. The RPMs already existed upstream so it theoretically should have been a pretty simple cleanup in line with Fedora Pacakaging Guidelines.
It took from 9/11/12 to 10/1/13 to get that from the initial big to approved...
The only existing codebase form which to discuss this and test a *working* office suite packaged by RPM is 3.4.1 ...
Right now there's no roadmap for 4.0 - no milestone dates, alpha dates or beta dates... The best that exists for this is a nightly snapshot from trunk covered in caveats about how unstable it's likely to be.
The openoffice.org wiki doesn't even mention 3.4 much less future plans for 4.0 on it's features page!
http://wiki.openoffice.org/wiki/Features
Could you have a chat with Rob Weir to clarify IBM's timeline for the 4.0 package and provide some hard milestone dates rather than the current vague "April 2013" ?
Annoyingly the AOO thread has split in my email client by I agree the discussion about the IBM Symphony dump ( licensing concerns as out of scope given that won't be packaged and all code will be review for license whilst being merged to AOO however this inject of proprietary code as opposed to the open tested code of 3.4.1 on a tight timeline is I would submit a concern as to the likelihood of bugs and slippage from the current vague date.
Out of curiosity I just downloaded the tarball (of x86_64 RPMs) on the oo.org website to see how they would behave whilst installing to my F18 system...
Yum reported no conflicts on install - which surprised me (although I didn't install the desktop integration stuff) - and then I noticed it installed to /opt which is an immediate violation of the packaging guidelines so there's not actually a reasonably clean (like the mariaDB ones were) to start from in the first place...
There's substantial risk here to the reputation of Fedora trying to squeeze this untested application into a F19 timeline when it's rushed into the distribution rather than taking a step back and working through the conflict issues (and others involved) and certainly with the 3.4.1 code no gain to Fedora users at all over the existing LibreOffice suite.
Realistically this packaging discussion should have been started back last year on the 3.4.1 release or shortly thereafter - perhaps with an apache supported but unofficial yum repository until such time as the RPMs fell inline with Fedora guidelines and then the discussion could have been had well ahead of the feature deadline for a release and definitely more than 3 weeks from branch...
On 05/02/2013 James Hogarth wrote:
Let's take a look at a similar (although of course not identical) situation [...] the MariaDB packaging review request.
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.
The only existing codebase form which to discuss this and test a *working* office suite packaged by RPM is 3.4.1 ... Right now there's no roadmap for 4.0
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.
The openoffice.org wiki doesn't even mention 3.4 much less future plans for 4.0 on it's features page! http://wiki.openoffice.org/wiki/Features
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.
Could you have a chat with Rob Weir to clarify IBM's timeline for the 4.0 package and provide some hard milestone dates rather than the current vague "April 2013" ?
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.)
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.
Actually, I didn't see licenses or copyright notices in the spec file, just a changelog. Could someone clarify the licensing status of spec files? Are they just "convenience files" that anyone can freely modify?
Regards, Andrea.
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.
On Wed, Feb 06, 2013 at 01:42:00PM +0100, Andrea Pescetti wrote:
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.
Policy does exist that would highly discourage an update from 3.4.1 to 4.0 once Fedora 19 is released:
http://fedoraproject.org/wiki/Updates_Policy#All_other_updates
Packagers do have leeway here and, ironically, the less popular your package is, the more you can get away with. But I would say that given your goals, the best version to ship would be a pre-release of 4.0 (or final if it is out).
Depending on how stable the pre-release is on Fedora, you may want to modify the release notes section of the Feature Page to reflect that it's a technology preview.
Actually, I didn't see licenses or copyright notices in the spec file, just a changelog. Could someone clarify the licensing status of spec files? Are they just "convenience files" that anyone can freely modify?
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#License_of_Fedora...
However, if you're going to run that by a lawyer, we should talk to spot first. Fedora switched from the ICLA to the FPCA: https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement?rd...
a while back. I'm not certain if that section on spec file licensing links to the ICLA on purpose or if it should have been updated to the FPCA.
(The differences between the two may be unimportant to what you want to do but I felt I should highlight it just in case).
-Toshio
James Hogarth wrote:
Right now there's no roadmap for 4.0 - no milestone dates, alpha dates or beta dates... The best that exists for this is a nightly snapshot from trunk covered in caveats about how unstable it's likely to be.
The openoffice.org wiki doesn't even mention 3.4 much less future plans for 4.0 on it's features page!
http://wiki.openoffice.org/wiki/Features
Could you have a chat with Rob Weir to clarify IBM's timeline for the 4.0 package and provide some hard milestone dates rather than the current vague "April 2013" ?
Annoyingly the AOO thread has split in my email client by I agree the discussion about the IBM Symphony dump ( licensing concerns as out of scope given that won't be packaged and all code will be review for license whilst being merged to AOO however this inject of proprietary code as opposed to the open tested code of 3.4.1 on a tight timeline is I would submit a concern as to the likelihood of bugs and slippage from the current vague date.
AOO really seems to have degenerated into IBM's private playground. (No wonder, they're the only ones who benefit from the braindead non-copyleft licensing.)
Kevin Kofler
AOO really seems to have degenerated into IBM's private playground. (No wonder, they're the only ones who benefit from the braindead non-copyleft licensing.)
Talking of licensing...
Since this has been approved I'm curious as to the method by which the non-conflict with LO is to be achieved...
I was browsing the AOO archives when I came upon Andrea's thread there about AOO in F19...
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201301.mbox/%3C51093...
Going through it Andrea has kept a very level head with respect to wanting to work with Fedora to get the packages built and in but there is a lot of dispute surrounding the oowriter etc situation...
Please read the full thread for context but as an example:
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201302.mbox/%3CCAP-k...
This made me think of the reminder that had to be given to Oracle about the Fedora principles and how friendship is a key one...
There's been little discussion of this since the earlier part of the month on either mailing list and and no commits to the LO git or bugzilla bugs I have been able to find about dealing with conflict and bringing this package in...
So what's the plan in mind?
Is the existing orphaned openoffice.org package in Fedora going to have Andrea as a maintainer and then this new code committed?
Is this considered to be a completely fresh new package to go through the usual new package guidelines (plus sponsorship for a new packager)?
Will Andrea be maintainer of the package or someone else in the AOO group? There didn't seem to be much enthusiasm there in packaging themselves...
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201302.mbox/%3C5112B...
That was the last message there and there's no wiki page I could find on the oo.org wikis about packaging for F19 and nothing the in oo.org bugzilla instance on issues.apache.org ...
So... plan?
Will Andrea be maintainer of the package or someone else in the AOO group? There didn't seem to be much enthusiasm there in packaging themselves...
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201302.mbox/%3C5112B...
That was the last message there and there's no wiki page I could find on the oo.org wikis about packaging for F19 and nothing the in oo.orgbugzilla instance on issues.apache.org ...
Apologies... right link on that last bit is:
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201302.mbox/%3C51143...
Hi
On Mon, Feb 18, 2013 at 11:55 AM, James Hogarth wrote:
This made me think of the reminder that had to be given to Oracle about the Fedora principles and how friendship is a key one...
Apache Openoffice has no connection to Oracle
Rahul
Apache Openoffice has no connection to Oracle
No it has more of a link with IBM - but I'm not talking about who the corporate sponsor is but rather the principles involved...
In the MySQL thread Oracle had to be given a reminder about friendship being an important principle... and here we are in the other divisive thread where another group might do with a reminder...
But this is the silliest nitpick from my question which is surrounding the next steps for AOO, how the conflicts will be resolved and how the package is being treated (pick up an orphaned package or a new package) plus who the maintainer(s) will end up being.
Hi
On Mon, Feb 18, 2013 at 12:25 PM, James Hogarth wrote:
But this is the silliest nitpick from my question which is surrounding the next steps for AOO, how the conflicts will be resolved and how the package is being treated (pick up an orphaned package or a new package) plus who the maintainer(s) will end up being.
Typically the person proposing the feature would be the maintainer and they would resolve the conflicts by talking it out with the Libreoffice maintainers.
Rahul
On Mon, Feb 18, 2013 at 04:55:55PM +0000, James Hogarth wrote:
Since this has been approved I'm curious as to the method by which the non-conflict with LO is to be achieved...
I don't know the answer to this. Hopefully Andrea is pondering it and working with the libreoffice maintainers if he needs to coordinate any changes with them. He could fill us in if he wants.
I was browsing the AOO archives when I came upon Andrea's thread there about AOO in F19...
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201301.mbox/ %3C5109384E.60606%40apache.org%3E
Going through it Andrea has kept a very level head with respect to wanting to work with Fedora to get the packages built and in but there is a lot of dispute surrounding the oowriter etc situation...
<nod>
+1 to Andrea.
Please read the full thread for context but as an example:
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201302.mbox/ %3CCAP-ksojB20qDs5ORK_nHiRj142-KosAPioSHC5yxCSTj6OVH1w@mail.gmail.com%3E
This made me think of the reminder that had to be given to Oracle about the Fedora principles and how friendship is a key one...
I don't know that this is an issue that Fedora needs to do anything about. As Fedora has experienced internally many time, contributors to a project can say anything they want as an individual but that doesn't mean the project is heading in that direction. Andrea, as our point of contact has been great and to my knowledge we haven't received anything from Apache Foundation Lawyers about use of trademarks so I don't think that this is something to chide the AOO mailing list about.
There's been little discussion of this since the earlier part of the month on either mailing list and and no commits to the LO git or bugzilla bugs I have been able to find about dealing with conflict and bringing this package in...
So what's the plan in mind?
For the general plan, Andrea will need to weigh in. Fedora Alpha change deadline is: 2013-04-02 so we're creeping up on a milestone where we might have to defer the Feature to F20. This is a leaf package so it might be okay to go in later but it does need 1) documenting in the release notes, so that imposes a deadline so that the release notes can be written and translated. 2) testing that there are no non-trivial/non-obvious problems between the libreoffice and aoo packaging so there is a deadline here.
Is the existing orphaned openoffice.org package in Fedora going to have Andrea as a maintainer and then this new code committed?
Is this considered to be a completely fresh new package to go through the usual new package guidelines (plus sponsorship for a new packager)?
For this specific question -- policy is that packages which are retired/deprecated need to go through re-review to get back into the dirtibution. So it's pretty much equivalent to a fresh new package where the packager would need sponsorship if they aren't already in the packager group.
Will Andrea be maintainer of the package or someone else in the AOO group?
Andrea will need to speak to this as well.
-Toshio
Toshio Kuratomi wrote:
On Mon, Feb 18, 2013 at 04:55:55PM +0000, James Hogarth wrote:
Since this has been approved I'm curious as to the method by which the non-conflict with LO is to be achieved...
We've looked at http://fedoraproject.org/wiki/Packaging:EnvironmentModules under FESCo's recommendation. If someone has an example of two packages from Rawhide successfully implementing this, it would be great.
I don't know the answer to this. Hopefully Andrea is pondering it and working with the libreoffice maintainers if he needs to coordinate any changes with them. He could fill us in if he wants.
We will definitely try and work with the LibreOffice maintainers. But we are not quite there about conflicts yet: you will remember from this thread that the situation is not so clear, and that for example the upstream LibreOffice does not ship the conflicting "soffice" alias while Stephan Bergmann, who is a well-known and experienced developer, clarified it is still useful in a number of cases and that it will be kept in Fedora.
I was browsing the AOO archives when I came upon Andrea's thread there about AOO in F19...
Reading the OpenOffice dev list may be a lot of fun! Your (James') recommendation to read the full thread is perfect, but for those who do not have the time to read it all, remember that the new OpenOffice dev list, even though it was born in 2011, is on par with this list in traffic, that it has around 450 subscribers (many of which like to post quite frequently), and that the Apache mailing list interface unfortunately does not allow easy thread linking/navigation, so in general you end up reading messages out of context. By comparison, imagine someone having to pick a few messages from the Cinnamon discussion on this list to summarize it... you would end up with some confusion.
Another point worth knowing about the Apache lists in general is that they apply "lazy consensus": if there is no opposition to a proposal in 3 days, it's considered accepted. So it can perfectly happen that there is no positive feedback about a proposal, since that is the default.
there is a lot of dispute surrounding the oowriter etc situation...
It will be clarified. The concern there started with the assumption that "yum install OpenOffice.org" would install something else. It doesn't, of course. So the following discussion is largely irrelevant, but again we will be following the FESCo's recommendation here.
This made me think of the reminder that had to be given to Oracle about the Fedora principles and how friendship is a key one...
If there is anything that you ("you"=="James" here, sorry for lumping two answers together) feel good to clarify, please do. I surely won't get offended if there is anything more to know. (I understand that Oracle is mentioned just for reference, as clarified later).
As Fedora has experienced internally many time, contributors to a project can say anything they want as an individual but that doesn't mean the project is heading in that direction.
Same for Apache Openoffice, obviously.
There's been little discussion of this since the earlier part of the month on either mailing list [...] So what's the plan in mind?
There's a separate thread about configure options which is about the Fedora packaging. I'll post updates there later this week, and I'll probably also take your suggestion to open a wiki page to summarize the ongoing work, since I really don't want to force anyone to read all threads in the OpenOffice dev list to stay up-to-date!
Is the existing orphaned openoffice.org package in Fedora going to have Andrea as a maintainer and then this new code committed? Is this considered to be a completely fresh new package to go through the usual new package guidelines (plus sponsorship for a new packager)?
For this specific question -- policy is that packages which are retired/deprecated need to go through re-review to get back into the dirtibution. So it's pretty much equivalent to a fresh new package where the packager would need sponsorship if they aren't already in the packager group.
We are basing on the old openoffice.org package at the moment, but if policy is really similar then it doesn't make a big difference at this stage. Admittedly, I've very little interested in the "political" side of packaging at the moment, so it's enough for me to know that, technically and procedurally, the two ways are roughly equivalent.
Will Andrea be maintainer of the package or someone else in the AOO group?
Andrea will need to speak to this as well.
I will be one of the packagers. I expect a couple of other Apache OpenOffice committers to be packagers too. If someone else wants to join or give advice, this is totally welcome: and remember that, despite what you may have heard around, no paperwork is needed to contribute to Apache OpenOffice, just jump in.
Regards, Andrea.
On 02/19/2013 07:50 AM, Andrea Pescetti wrote:
It will be clarified. The concern there started with the assumption that "yum install OpenOffice.org" would install something else. It doesn't, of course. So the following discussion is largely irrelevant, but again we will be following the FESCo's recommendation here.
The other concern being that you cant have both installed at the same time and or when they do they conflict with each other as in John wants and uses libreoffice Mary wants to use openoffice.
John configures Gnome to default open every documentation and tool with libreoffice whilst Mary does same but for openoffice. If neither one winds up using/running each other applications and binary's then this does not need to be discussed any further.
JBG
On Mon, 2013-02-04 at 07:47 +0100, Kevin Kofler wrote:
Jaroslav Reznik wrote:
= Features/ApacheOpenOffice = https://fedoraproject.org/wiki/Features/ApacheOpenOffice
Feature owner(s): Andrea Pescetti pescetti@apache.org
Add Apache OpenOffice, the free productivity suite, to Fedora.
A big -1 to this feature, and in fact I'd urge FESCo to veto that package outright (or if it somehow already made it into Fedora, to get it blocked in Koji and Obsoleted by libreoffice ASAP).
Kevin, could you *please* stop essentially sending the same mail seven times? I mean, I know I'm guilty of over-posting at times, but this is just ludicrous. I think by the fourth mail in this little set you just spammed, everyone was pretty clear where you stood on the *Office question.
If you get behind on reading the list, it is not a good idea to just read through one mail at a time and send replies to each one as soon as they spring into your head. Read *all* the posts first, then write one or two mails that include any points you have to add to the discussion that are actually original and haven't been posted by five other people already. And make it just one or two mails, not seven in a row.