Hi Mathias, all,
Mathias Bauer a écrit :
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.
Thanks :)
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.
Helge has answered here, the Analyze errors function gives an overview
of the differences between MWS and CWS with Automation CAT0, so it is
fast and easy.
- 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.
Sepcs are important for people like me for several tasks we achieve in
the project : for QA tasks (closing an issue verified in a CWS, doing
TCS on dev snapshots, etc), localization (you can't localize correctly a
new functionality when you only have strings lost in several files or
the UI, check for integration errors) and documentation.
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.
Not only, sometimes changes are not documented because the corresponding
CWS has not been mark help relevant, having an issue in the CWS tasks
list would help to make sure (or at least give a chance that) it will be
documented in the same release the CWS is integrated.
- 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?
We have already talk about improving the process on the l10n list and at
the last OOoCon also. See the thread here :
http://l10n.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=10607
As said, I'm not technical enough to know what would be the best tools
and process, but I'm used to SCM and I can understand the benefits we
can gain here. So what you described above using Mercurial is a kind of
dream I'm sure all l10n teams would like to see happen :)
It may be not relevant for the discussion here, but we have had to fight
against integration issues, formatting issues, development issues,
etc... I've spent hours translating strings that were not integrated or
seen changes finally reverted.
So for me it's not only a localization process issue but a better
coordination/communication between the development process and the
localization process.
Kind regards
Sophie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
