Andrea Pescetti wrote:
Marcus Lange wrote:
Andrea Pescetti wrote:
Hi Andrea,
Well, I would consider it a broken link, it's a link to something that
does not exist.
sorry no, my option is different. A non-existing link is not a broken
link as it hasn't worked ever.
OK, this is just a matter of definitions; I'm sure we both want the same
Of course, there are mostly two sides of the cookie.
thing, i.e., that the user is always presented with the valid link.
ACK
We cannot produce exceptions for special
builds because team A has approved it but team B not. IMHO there has to
be a common basis. ...
I don't know why it should be a burden to do one of the most importent
thing in QA: testing and approving. ;-)
Well, this really puts on the N-L teams some responsibilities they
shouldn't have. Some teams (not the case of the Italian team, I'm
Thats a surprise for me: When the respective L10N team has not the
responsibility to release their language builds, how has it?
speaking in general) may not want to approve with-JRE builds because
there does not exist a JRE in their language and they prefer not to have
it bundled; or their testers refuse to run non-free software (and, as
Ah yes, the old problem.
far as I know, the shipped JRE is still non-free); or they don't have
enough demand or enough testers to approve all builds.
Besides the free/non-free problem, when they have the tester to approve
the nonJRE build, then the same could do it with the wJRE build. ;-)
About time, when testing, e.g., the Win nonJRE build deeply then it
should be enough to just have a look if the wJRE still unpacks, install,
show the correct language and still compute basic things like
load/save/print, etc. Of course I don't know of the TCM tests and how
detailed and long they are. In this case I would say 1 hour testing for
the additional build is maybe already too long.
But I'm not a tester, so maybe my view is not correct. ;-)
We shouldn't force them to approve builds (perhaps carelessly) just
because this way the download system will be easier to maintain. I
repeat, there is only one way to do it, and it is to fix the download
system.
No, I don't want to force anyone. I just thought that it should be
possible to test and approve also the second build when the first is
released.
Mirrorbrain cannot produce anything as it is "just" a redirect system.
And fixing the download system for every release is no solution. If
there would be *at least* a fixed set of builds we could create it out
of this. But at the moment it's not; at least not really complete.
MirrorBrain, or a preliminary handler, is able to produce the MD5 hashes
for instance:
http://download.services.openoffice.org/files/localized/it/3.2.1/OOo_3.2.1_Win_x86_install-wJRE_it.exe.md5
This is not complex and already built-in ...
and it is surely able to put the output of "find ." somewhere, in a
format JavaScript can parse, and to produce a list of valid builds, to
be used by the selection JavaScript to know whether a build is
available.
... but creating HTML/JS code is IMHO a different thing. And it is not
yet available and has to be implemented before it could be used. So,
even this is no fast solution. ;-)
Please believe me, sometimes it's really a pain to find a solution on
the webpages for every new exception. ;-)
Yes, I can understand it's really painful to deal with multiple
architectures, language conventions, browser sniffing and that... But I
really believe that we just need this little link between MirrorBrain
and the download site to solve virtually all the problems due to delayed
approvals, non-approved builds and so on. It would probably make your
life easier too, and seems rather easy to do and absolutely sustainable.
Lets see what the future will bring. Unfortunately, at the moment there
are no resources to rebuild the download system.
I also have some ideas how to improve the download offering. But it
cannot be done in the near future. So, I thought about things that could
be done faster and thats why I came to you with this request. :-)
Best regards
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
