On Tue, 28 May 2013 13:57:42 +0200 Jürgen Schmidt <[email protected]> wrote:
> On 5/28/13 1:03 PM, janI wrote: > > On 28 May 2013 09:38, Jürgen Schmidt <[email protected]> wrote: > > > >> On 5/27/13 11:46 PM, Rob Weir wrote: > >>> On Mon, May 27, 2013 at 12:58 PM, janI <[email protected]> wrote: > >>>> On 27 May 2013 17:17, Jürgen Schmidt <[email protected]> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> I would like to discuss our further schedule towards AOO 4.0 and the > >>>>> problems I see. And I would like to discuss a proposal how to address > >>>>> these problems. > >>>>> > >>>>> We are behind our schedule a little bit and we have identified some > >>>>> problems regarding the 64bit port on MacOS that I will try to explain > >>>>> below (hopefully without too many technical details that everybody can > >>>>> understand it). > >>>>> > >>>>> Proposal > >>>>> ======== > >>>>> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes > >>>>> (all platforms) asap into trunk and include them in AOO 4.0. > >>>>> > >>>>> - Move into showstopper mode next week, beginning with June 3th. Means > >>>>> we integrate only showstopper flagged issues and new translations. And > >>>>> potentially new art work if we get a new logo and icons in time. > >>>>> Deadline for new art work should be June 10th. > >>>>> > >>>>> I understand your motivation and will not be the showstopper. but my > >>>> honest opion is that the reasons for calling it 4.0 get very thin. > >>>> > >>> > >>> You might want to put your negative quotes into their own threads to > >>> make it easier for those opposed to the project to find it and put it > >>> into Wikipedia or an article. > >> > >> both comments from you both doesn't help us in any way to move forward > >> with our release or address the topic that I tired to discuss. > >> > >> For the record I am NOT opposed to the project, if I were I would not do > > that much work for the project. > > We know and we appreciate what you are doing. > > The point is that we are not in a perfect world and here in our project > it's the same. We have to live and work with certain circumstances and > have to make the best out of it. > > The key question is what is the best solution to move forward and don't > postpone our release to long. I really would like to have a release with > the sidebar before LO. Well it's not critical but I would prefer if > possible. They have already integrated the sidebar in their 4.1 branch > as experimental feature. It will be interesting to see how they > communicate this feature. > > Juergen > > > > > > Juergen, you are quite right, please go ahead as do as you think are best > > to get the release out as soon as possible. > > > > rgds > > jan I. > > > > > >>> > >>>> Getting a 64 bit release for mac (and possible in linux) is something > >> (as > >>>> you write) for a major version and not a minor version like 4.1. > >>>> > >>> > >>> We already have Linux 64 bit. > >>> > >>>> I am against (but will vote -0) of making a release just to hold the > >>>> deadline, I would very much prefer to see what a realistic deadline > >> would > >>>> be. > >>>> > >>> > >>> Fortunately publishing a release at Apache requires only three +1 PMC > >>> votes and there are no vetos. The process is biased toward making it > >>> easy to release. > >> > >> we need no discussion in this thread about the proceeding how we do > >> releases here at Apache. We already did it twice and if people want to > >> discuss it please in a new thread. > >> > >> In this thread I would like to discuss the technical issues around my > >> proposal and the impact on our release oo how we want to move forward. > >> > >> Juergen > >> > >>> > >>> -Rob > >>> > >>>> rgds > >>>> jan I. > >>>> > >>>> Ps. You do a great job as release manager, but someone has to be "devils > >>>> advocate". > >>>> > >>>> > >>>>> - Intensive QA with the stlport changes to detect potential problems > >>>>> > >>>>> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully > >>>>> have integrated already returned translations. > >>>>> > >>>>> - Translation deadline will be set to June 14th to have some time for > >>>>> the integration and further testing. Further translations can we > >> release > >>>>> at a later time as a special language update release (TBD) > >>>>> > >>>>> > >>>>> > >>>>> I would still like to keep the end of June date because everything else > >>>>> looks quite nice and we should give our users the new sidebar. > >>>>> > >>>>> A shifted release date won't really help us because we will move in the > >>>>> vacation time and I think it is better to bring the 4.0 version out > >> before. > >>>>> > >>>>> Once we have solved the mozilla problem for the 64bit version we can > >>>>> decide if we want release a 4.1 immediately or later together with > >>>>> further improvements, fixes and further languages. > >>>>> > >>>>> > >>>>> Background Explanation > >>>>> ====================== > >>>>> > >>>>> Herbert did a great job with his ongoing work to port AOO to 64bit on > >>>>> the MacOS platform. This work is mainly triggered and motivated by the > >>>>> deprecation of some system abi's and the drop of 32 bit Java. In short > >>>>> we switched to the clang compiler, a new platform SDK, XCode4, replaced > >>>>> for example atsui API with CoreText, get rid of stlport (on all > >>>>> platforms) and did many more cleanup that work that were necessary > >>>>> because of better and/or different compiler/linker behaviour or error > >>>>> messages etc. Everything looked quite well until we focused on the > >> still > >>>>> used precompiled older Mozilla libraries. We currently struggle with > >>>>> porting this stuff to 64 bit and evaluating if we can get rid of them > >>>>> completely. A complete drop of the mozilla libs would be a further huge > >>>>> improvement but it is of course a lot of work to understand the code > >>>>> first and all dependencies and to replace it with some new code... At > >>>>> the moment we see this on risk for AOO 4.0 and plan to postpone this to > >>>>> 4.1. > >>>>> > >>>>> But the drop of the stlport lib is relevant for all platforms and will > >>>>> introduce a binary incompatibility. The best and only time for such an > >>>>> incompatible change is a major version. The plan is to extract the > >>>>> stlport relevant changes and merge them on trunk asap (this week). This > >>>>> will decouple any further work on the 64bit port and we can release the > >>>>> 64bit version at any time later (as 4.1) because the 64bit version is > >>>>> based on a completely new platform on MacOS additionally to the > >> existing > >>>>> one. > >>>>> > >>>>> The 32bit version will be part of the AOO 4.0 release and we will need > >>>>> this version for backward compatibility on older system anyway. The > >>>>> 64bit version will run on 10.7 and newer only. > >>>>> > >>>>> > >>>>> I am looking forward to any constructive feedback or concerns. > >>>>> > >>>>> Juergen > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> I suggest that AOO 4.0 should be released as soon as practicable; if some major section (Mac 64?) is not ready, then the release of the main body of work should not be delayed to await such a section. The non-release of any delayed section can be noted and promised for RSN (Real Soon Now, if anyone remembers early CP/M days) and released as and when ready, without being held for AOO 4.1 To miss the intended date will leave the AOO project open to derogatory comments. -- Rory O'Farrell <[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
