Christian Lohmaier wrote:
Well - I did ask for an explanation on why it makes a difference on why it matters whether Sun provides the builds or some other person provides it. I asked how the customer/user can make the builder "responsible" for whatever consequences of the use of OOo. (Or why that kind of "accountability" is only possible if the builder is Sun, and not any other contributor).
The primary reasons why I did not answer the topics were: - The discussions between Eric and André had already mentioned the direction of this thread. - I felt no need to *explain* since I was not your employee. Whatever you could ask anybody to explain, they could choose what they answer. If you were I, did not you think so? So, I mentioned about the discussion first in the prior post of mine, and added one topic that would not be covered by the discussion. tora - Takamichi Akiyama wrote: > According to the discussions between André and Eric, I think > we can leave this to them and/or the Mac porting team. Anyway, you asked me them again, I am trying to respond to your inquiries. ===== It is trustiness and openness. Which is superior, priced software product or open source software product? Nobody can, in general, answer to the question. It depends on what factor a customer considers important. Responsibility of priced software products is based on monetary balance; responsibility of our open source software product, OpenOffice.org, is based on trustiness and openness. That is my thoughts. Trustiness We have been delivering our software products to our customers for years and showing them how our products can be trusted. The process of development, schedule, features, criteria of testing products, how to handle bugs, etc. are truly open and done professionally. In this thread's case, unfortunately and coincidently, the build process of Mac binaries by the single person is being in question. - We cannot test the inside of a software product during release sanity test. What we can do is to open a package, to turn on the product, and to observe if it works fine. We do not have a X-ray system that might find a micro-sized eavesdrop device or bot in the product. - We can completely review source code of open source software product. We cannot check its binary once compiled from the source code into machinery code. Anyone, not to mention, including you and I, can intentionally or accidentally replace some files to be packed in a binary package just before uploading the package and then state this product is based on this open source code. - Sun's build is done by a team consisting of some staffs while the personal build is done by a single person. If it is done by a single person, it would be harder to completely remove the possibility of the flaw. - We can trust the person, but we cannot truly trust the way of build process if it is done by a single person. You might complain saying no difference between done by a single person and done by a team, but I would like to say that team work in a well-organized firm is greatly better than single person's work. So, it can be said a way done by a team is systematically more trusted than done by a single person. Another aspect. It seems current build process regarding Mac binaries is done by a single person. I don't know how many machines are used. If a build process is professionally done, there must be at least three real/virtual machines for each platform: 1. Build machine Build machine is a machine to build software products. This machine should be a pure machine that does not have any unnecessary software installed. 2. Sanity check machine Sanity check machine is a machine to confirm if the build is succeeded before uploading a built binary. This machine should not have any tools required by the build process. A built binary normally works well on a build machine since all necessary files are installed in the machine while it sometimes does not work well on a user's machine due to lack of some files. So, this machine imitates a user's machine. 3. Debug machine Debug machine is a machine to reproduce and look into a problem reported by a user. This debug machine should be isolated from any other machines, since it is used to open alien document files sent by foreign customers. Even though a build machine has all files for debugging a problem, the build machine should not be used to investigate the problem. In addition to the machines, if the builder needs to read e-mails or to visit web sites, he definitely needs another machine for the purposes to avoid computer virus infection. The requirement above seems a little bit beyond a single person's capacity. If the builder mixtures the machines, his build process is somewhat hard to be technically trusted from the beginning. Not to mention, Sun understands the requirements and utilizes individual machines. Openness Openness is one of the strong points that we can offer to our customers. When a customer encounters a problem regarding our product, OpenOffice.org, she can search information on the similar phenomenon in the Internet and/or report it to local and/or English mailing lists, BBS, and/or forums. Then, it will be filed in the issue tracker if it has not be filed yet. The process of investing the cause, fixing the problem, incorporating the fix into upcoming release, ... is amazingly open to the public. This type of openness is normally not available with proprietary software products. To make users satisfied from accountability's perspective of view, we should promptly respond to a problem that they encounter. To quickly and efficiently attack the bug, we, QA team and responsible developers from relevant project, definitely will need build environment that produced the OpenOffice.org that the customer has been using. If the build is secretly done by a single person - I do not wanted to choose this word 'secretly' here, but in reality - and its build environment is not open to the QA team or the developers, how can we effectively attack a bug and how can we provide our best accountability to our customers? The builder can send his entire build environment to them. But why do we need to make things so complex? To keep trustiness and openness of our official products more than certain level, this thread goes, I think. And I would like to respect the idea mentioned in the article posted by André, cited below: André Schnabel wrote: > Eric - Two people started the discussion, claiming that somthing is > uncler. They got response from: > - Current QA project lead > - Current QA co lead > - former QA lead > - Mac Porting lead > - Localization QA team co lead > - long term QA member > > most answered in a similar way. "The recommendation at the moment is to > use Sun builds. but if these are not available take any build and do QA > tests on these." > QA Leads agreed to write this down so that it is better visible. The point might be what our customers and users would find of our software products and project rather than what we internally think of them. Regards, Tora --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
