Hi Sophie, thank you for your comments. I'm glad to get feedback from "non code hackers" also as I'm hoping to make life easier for them also.
I will add your points to my list. Let me give some immediate answers to some of your points. I will come back if I can say to one of the other points I have put on my list for now and snipped in my reply. Sophie wrote: > What a community member like me has the most to fight with when doing QA > is time. It's not very hard to check for issues, to run VCLTestTools or > write TCS, but it takes a lot of time for each (and also a lot of time > to learn to do every thing the right way, but it's really a very good > experience thanks to the e-team I've worked with :). > > Tools are not so difficult (for a non technical person like me) and I > found that dealing with EIS (the QA part) is really helpful. > The good points : > - Termite to build install sets > - Ability to run the Automation CAT0 on Sun servers > - Direct upload of the tests results on QUASTe > - Comparison with MWS, you just have to run again the fails locally. Really, this part of the work is superfluous. IMHO tests that are known to be broken in a particular milestone should be skipped in a CWS based on it also. So if you get a "red" state, you know that something is wrong without the necessity to browse through Quaste. I hope that this will be changed, but I don't know what the Sun QA engineers working on the autotests are planning. The testing procedures themselves are not part of our effort to improve the build environment, so I can only guess. > - EIS allow a very good coordination between all of us. > All this chain is really time saving (your own machines can rest ;) Thanks, it's good to get some positive feedback also. :-) > Concerning the localization process. Well, we still have a lot of things > to improve from my point of view. A better communication and > coordination with developers may have its place here more than our usual > complains against Pootle. So yes, > - helpcontent should be part of the concerned CWS, if it is mark that > the help is concerned, then the corresponding task should part of the > CWS issue list > - there should not be a new CWS added to SVN with no spec or a detailed > issue Well, we always advertized the value of specs, it's good to read that this opinion is shared by those who we saw as "consumers" of specifications. Whether help content must be part of a feature CWS or not should be seen in the general context of how we want to localize it. > - I support your idea of working with SCM, if well documented I'm sure > we will be able to get the support of other l10n teams to work on CWS > and mercurial, and more if that avoid us all this mess up in the last > snapshots. Currently the way how localizations get into OOo is very inefficient. At some point in time a "deadline" is reached and a whole bunch of localizable content is exported from the source tree and handed over. Localizers do their work, send it back and have to wait until Sun release engineering has collected it and provided a new build containing all the work. If bugs are found, the next round follows. I think we can do better. My idea for a long term goal is that all localization related content (help, UI etc.) resides in an own Mercurial repository that localizers can check out and directly commit to (if they want). A *simple* build process (that does not require to check out the whole OOo source) allows them to test their results themselves and immediately correct errors, but that would be optional. Of course it should still be possible to work as today (send changes to Sun release engineering), comparable to the situation of code contributors that either can create an own CWS or send in patches. In a system like this localization even does not need to have a deadline. Once a feature is done and documented, it can become localized. Whether we want to do that is open for discussion. We are far from that idea - one necessary precondition for it would be to free our l10n builds from using the OOo Resource Compiler and I'm sure there are other obstacles, but basically I don't understand why it shouldn't be possible. As the localization is very important for OOo the effort to improve its process surely would be justified. What do you think? Of course I don't want to impose something on others, but perhaps many people would like to work in such a faster and more flexible way, even if it needed some work on the build environment and some change in working style of the l10n teams. Maybe nobody dared to ask for that because it was considered to be improbable that something like that could be implemented? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org