I have the additional concern that UOF integration may be disrupted by a rebasing on Symphony (approach II). It depends on how close UOF was working against an OO.o base that is essentially retained by AOO (approach I).
Last year, I did some *very* limited interoperability testing of Symphony support for ODF package features and I found inexplicable differences in the handling of packages, especially ones having ODF 1.2 digital signatures. I have not tested enough to determine how close Symphony 3 is to some version of OO.o in terms of ODF support and have no opinion about that beyond wondering what it is and if there is an impact if rebasing on Symphony were attempted. - Dennis -----Original Message----- From: RGB ES [mailto:rgb.m...@gmail.com] Sent: Tuesday, June 12, 2012 01:36 To: ooo-dev@incubator.apache.org; orc...@apache.org Subject: Re: Next steps for Symphony and AOO 2012/6/12 Dennis E. Hamilton <orc...@apache.org>: > Predictably, I prefer approach I on first principles: > Never derail the train that's running. I think this is fundamental: big changes on short times will give enormous problems to the current user base, not only because the obvious need to learn something new, but also for the inevitable load of new bugs. AOO is a user oriented system, so we need to put our users first by avoiding any regression and limiting the annoyances. I think we can learn a lot about the "KDE 4.0" experience: even if KDE 4 started to be wonderful after 4.3, even now on the 4.8 era there are people still protesting because the disastrous experience with 4.0... Four years have passed! Option 1 is slow, but as my grandmother used to say "walking slow you'll arrive far" Regards Ricardo
