I second Clytie's statements below. First, we need to put out a quality product. Timelines be damned. If it takes a major manufacturer SEVEN YEARS to put out a major update, why should it take us three months. Second, there are MAJOR issues that need to be fixed. Testtool on the Mac Intel platform is broken, I will NOT release another issue until this is fixed. This will take major effort on the Mac OS X porting team and the UNO team to get this fixed. Third. We are volunteers for the most part. It may be good for SUN to announce that StarOffice 9 will be released on a certain date, but that raises our stress levels. Fourth. There are beginning efforts to get some of the languages fixed (finally). This means overcoming localization issues and other things. If we rush these folks then they will become frustrated and quit on us, just before a major breakthrough that will make their and our jobs much easier over the long run. Fifth. I do QA for a living. I know that it is very hard to get some issues resolved to everyone's happiness. Six. Our product, OpenOffice/StarOffice has to be as good as or better than any commercial product available. Our major competition is Microsoft Office. Sure it does not exist, for now, for the Linux platform, for now. This is a minor consolation when I work with MS Office all day and have to work with a broken, abet free, product all night. However, it does for the platform used by a vast majority of computer users (sorry Linux folks, but you own less than 10% of the desktops, worldwide) and that is WindowsXP. Seven. We cannot count on "initiatives" to win us friends. I don't care that OpenDocument is a mandated requirement. Until Microsoft provides it, it ain't happening. Sad, but true. Eight. We need to start working on old issues to get them fixed. One thing that bothers me is to see an old issue marked as a duplicate of a new one. The process should work in reverse. Sorry, this may mean going through duplicates and then moving the stream the other way.
I also know that no software will ever be 'error-free', but we must keep this in mind: Will a common user be able to utilize this software? Will the problem I encountered be one that an ordinary user will encounter? How many users will be impacted by what I just found? Is there an EASY workaround (must be one or two steps maximum) to the problem that I encountered? Is there an EASY fix to the problem I just found? Will this problem result in user abandonment of this product? (If so, this is Priority 1 and no other.) Remember this axiom: If one user likes this product enough to make it their primary product they will tell at most four more that will start to use the product. If they hate or dispise this product they will tell one-hundred NOT to use this product. Word of mouth is our best advertising, let us give it the best product. For now, I suggest that we abandon any release timeline, freeze the product feature wise and start fixing the problems we have encountered. James McKenzie -----Original Message----- >From: Clytie Siddall <[EMAIL PROTECTED]> >Sent: Dec 17, 2006 10:03 PM >To: [email protected], [email protected] >Cc: [email protected] >Subject: [mac] Release intervals > >To: l10n, releases >CC: mac-porting > >Hello everyone :) > >I am very concerned about the current three-month release interval. >When I first arrived here, with our fairly complete interface >translation, I was met on the lists with a mélange of information >about impending version 2.0.4 and upcoming version 2.1. That was >confusing, and I had to filter out all the stuff about 2.0.4 and >focus on 2.1. > >2.1 has just been officially released, but there are still QA issues >for different teams and architectures. I hope to release our (vi) 2.1 >builds fairly soon, but there is at least one pan-language stopper >bug (on Mac Intel), and a fair bit of specific work to do yet. > >And the translation deadline for OpenOffice.org 2.2 is January 18th, >only a month away! > >So what do I do? Abandon 2.1 and work on the translation updates for >2.2? Finish 2.1 and not be ready for 2.2? > >We have a set of major goals for 2.2, including translating all the >Help section (nearly half a million words) and improving support >information (docs, website, spellchecker etc.) in general. On this >time-scale, we'll be lucky if we get even the interface update in. > >I have participated in a discussion on the releases list about >changing the release interval to six months. What is the status of >that discussion? > >It's essential that we construct a more realistic release schedule, >or we are going to be faced with the choice of releasing buggy >builds, or not releasing at all. We simply need more time to create a >high-quality product. > >OpenOffice.org is far too complex a product to release every three >months. It should compare itself, not with single-program projects, >but with complex multi-app projects like the systems: GNOME, KDE, >Xfce, Debian. > >I recommend comparison with Debian, which has a culture of >excellence. Debian "Etch" will be released about 18 months after >Debian "Sarge". Meanwhile, users can get early builds, but the >official release has been polished and debugged very thoroughly. My >team had its first Debian translation basically ready over a year >ago, and people have been using it, but the extra time gave us the >chance to QA our translation extensively, and to translate support >materials. I will be happy and proud to release Debian officially in >Vietnamese for the first time. But I can only release our initial >OpenOffice.org translation (2.1) by seriously compromising the >quality of version 2.2. Or release 2.2. by dropping 2.1. > >We need action on this. I for one refuse to push out releases on this >schedule. It doesn't allow sufficient time to do a quality job. It's >sloppy and unprofessional. Our users deserve better than this. > >Please extend the release interval to six months minimum. Do it now. > >from Clytie (vi-VN, Vietnamese free-software translation team / nhóm >Việt hóa phần mềm tự do) >http://groups-beta.google.com/group/vi-VN > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
