On May 27, 2013, at 2:46 PM, Rob Weir wrote: > On Mon, May 27, 2013 at 12:58 PM, janI <j...@apache.org> wrote: >> On 27 May 2013 17:17, Jürgen Schmidt <jogischm...@gmail.com> 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. > >> 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.
The main process is mechanical. My check list: (1) Is the packaging complete? (2) Are the signatures and checksums on the packages correct? (3) Is the signature that of the Release Manager? (4) Are the LICENSE and NOTICE file included and correct? (5) Does the source release match a checkout of the release tag from svn? (6) Is the RAT report on the source package clean? If not, are only a few files incorrect? If any of the above is a definitive "NO" then I am "-1" for good technical reasons. An answer of "NO" to (6) becomes a judgement call on the meaning of "few". If all are "YES" then I am "+1". Following the above protects our users by assuring that the IP is properly licensed and that released packages can be authenticated by them. (Leaving out the fact that this authentication is hard and non-standard. Leaving out any discussion about digital signatures.) Given the large number of packages in our releases I would like to discuss how we can automate performing our checks. A good starting point would be configuration that is used to support the download page. Regards, Dave > > -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: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
