To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=70139
------- Additional comments from [EMAIL PROTECTED] Fri Oct 6 10:04:41 -0700 2006 ------- @All Not a show stopper! Alright, assuredly there is a definition of the term and applying this definition would lead to this conclusion. However, before a quick decision is made to release with the anomaly and target for 2.1 - 4 months away I suppose - consider this. This will be an anomaly that is in the face of many people. Surely not the majority of end users for whom Writer is the main module. For those more focused on the Base module this will, IMO, be 'a red nose'. Particularly those trying to migrate from MS Access to Base, as much of the functionality in the former can only be achieved with the use of scripts in Base. Two issues of timing come immediately to mind: First – OOoConn just wrapped up, a major focus of this conference seemed to be extensions and support for building them. Indeed a number of industry observers seem to have picked up on this in their writings. This update to the UI for binding events to procedures and now objects, it appears to me, is the first visible change to the application to support this new focus. Second – Base is including a major change to the module with the inclusion of QiQ support. This has been announced and many people are eagerly awaiting the 2.0.4 release for this new feature. What a shame it is indeed to offer this, perhaps the first major enhancement to the Base module since 2.0.0, and then dilute the momentum by simultaneously introducing this problem. The same could I believe be said about the interest and positive industry reporting regarding the extensions initiative. Just to be clear, I am not saying that this must be fixed before a final release. I have no real basis to make that judgment call. But surely it is worth the time for the developer(s) of the code to perform a review, bringing in whatever QA resources are needed, and then making a risk assessment as to whether the effort should be undertaken. I don't believe that in this case the call should be made purely on the basis of the calendar. If a concerted effort can be made to rectify this, and perform the needed QA in say a week then my vote would be to delay a week. If, in the judgment of the developers and QA staff, it would be three weeks – well that is a different case isn't it, and perhaps a different conclusion. Perception - at times it is very important, at times almost as important as reality, given enough, negative perception particularly, and it becomes reality. >From a strictly functional basis this is not a huge problem, for as has been pointed out there is a work around. But from a perception basis it has the potential to bring real questions as to the quality of the development processes being employed. Personally, I do not believe those perceptions to be reality in the slightest, but why allow the discussion to even begin if it can be mitigated ahead of time. Just my opinion on this. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- 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]
