On 06/11/12 22:24, Dennis E. Hamilton wrote:
Predictably, I prefer approach I on first principles:
Never derail the train that's running.
From that perspective, there's all of this:
- All of the developers and many testers and others know
how to build AOO 3.4.0 including people who are working
from the source tarball and the folks working on LibreOffice
and other co-dependents as well
- the current community includes those who build special
distros (of OOo and LO), provide QA that serves all of us,
etc.
I don't think the build procedure would change much at
all, but a change would be good. I don't think anyone is
proud of the current build system-
- There is still IP clearance to be done on the Symphony
contribution bits and that can be worked through selectively
as staging of features/fixes before merging to the SVN trunk.
That is rather minimal from what I have seen (ucpp).
- Alignment of the symphony code can be done off-trunk with
merging of selected features and fixes on an iterative basis
accompanied by testing of various kinds and localized attention
to build breakers and other potential regressions.
That is likely to be very difficult, and is the reason why alternative
II is being proposed. Symphony already works and builds on it's
own.
- There is an abundance of bug reports and analysis based on
the current lineage.
- All of the documentation, forum contributions, MediaWiki
and user lists are currently oriented around the OOo-lineage
and they need to be morphed in a progressive way, not a sudden
switch.
I am afraid this is something that just has to be done either
way. Some bugs are simply old and a lot of the
documentation is obsolete or under uncertain copyrights-
- Users and others may like new features but for many sudden
switches are unsettling
- Plan II could end up with us having to maintain OOo-lineage releases
and Symphony-merged releases concurrently. That is a frightening
prospect. It is like forking ourselves and maintaining both forks.
- Then there's the localizations, etc. that would crash against the
forked support, etc.
We would focus completely on the 4.x release after 3.4.1 is
released so I would expect we would EOL 3.4.x soon. We
would indeed be forking the code though; not sure what
would happen with "base".
The real question here is what works better for the people
doing the work. For me it's easier to take patches from
OOo/AOO and merge them than to try to extract features
from Symphony, but it would be interesting to hear what
the ex-Oracle guys have to say.
Pedro.
Dennis
-----Original Message-----
From: Rob Weir [mailto:[email protected]]
Sent: Monday, June 11, 2012 18:08
To: [email protected]
Subject: Next steps for Symphony and AOO
As we wait [0] for the Symphony [1] code to be loaded into Subversion
I think it would be good to start a discussion on "next steps" of how
we can make best use of this contribution.
Hopefully you've had time to review the list of features on the wiki
[2], install one of the binaries [3] , or maybe even download the
source [4] and try to build it [5].
As will see by your examination, the Symphony code base has co-evolved
with OpenOffice.org for several years now, and continued to co-evolve
with Apache OpenOffice even recently. Symphony has many features and
bug fixes that AOO lacks. And there are areas where Symphony is
missing enhancements or bug fixes that are in OpenOffice.
Our challenge is to find the best way to bring these two code bases
together, to make the best product.
I think there are two main approaches to this problem:
I. Merge code, from Symphony, feature by feature, into AOO, in a
prioritized order. This is the "slow" approach, since it would take
(by the estimates I've seen) a couple of years to bring all of the
Symphony enhancements and bug fixes over to AOO.
II. Use Symphony as the the new base, and merge (over time) AOO (and
OOo) enhancements and bug fixes into the new trunk. This approach
quickly gives a new UI, something we could fairly call Apache
OpenOffice 4.0. But this approach would also give us some short-term
pain. For example, those involved in porting AOO 3.4 would need to
merge their patches into the new trunk. We'd need to update license
headers again. Help files and translation are done differently in
Symphony, and so on.
Looked at another way, option I is a slow, but easy path. Option II
is a leap forward, but will be initially more work and disruption.
Evolution versus Revolution.
So let's discuss. Please ask questions about the pro's and con's of
each approach. The code and binaries are all posted, and my IBM
colleagues in Beijing are happy to answer your questions.
Regards,
-Rob
[0] https://issues.apache.org/jira/browse/INFRA-4799
[1] http://wiki.services.openoffice.org/wiki/Symphony
[2] http://wiki.services.openoffice.org/wiki/Symphony_contribution
[3] http://people.apache.org/~zhangjf/symphony/build/
[4] https://svn-master.apache.org/repos/test/danielsh/symphony-import/
[5]
http://wiki.services.openoffice.org/wiki/How_to_build_Symphony%27s_source_code
