Hi Charles,
Charles-H. Schulz schrieb:
Hello Thorsten,
2. There are issues in IZ which aren't related to OOo (vanilla). They
are for OOo builds by other Linux distros.
Yes, but there are also so many other bugs we don't know about...
I do not know, what do you mean. Which bugs we do not know? In which
product?
Sorry, I meant: there are so many bugs in Linux distros we don't know about.
But aren't the bugs parts of the distros and not part of the
mother-project OOo (vanilla). So why they do not spend resources
to check their versions accordingly to get the same quality as
the vanilla OOo.
For me the products by Ubuntu etc. are still different product. The
distros make changes (major and minor) in the product but they do
not change the name of it. But the users of the products give the
OOo project the feedback, that the qualities are different - because
the products are different. So should take the mother-project (vanilla
OOO) the responsibility about the quality of the other products?
Personally I am not willing to spend resources by my team to work on
quality assurance tasks for these products, only why the other project
do not do their jobs. Also I do not have any possibility to address one
of the found issues accordingly (therefore I asked for processes). The
same for the OOo community. We all cannot make pressure on Ubuntu or
Go-oo to fix an issue. They released and will release their products
anyway. Beside this : We are all in a business world - Novell, Ubuntu,
Sun, Oracle ... - so why should OOo project take over work, which have
to be done by the companies which want to make money with their
products?
The OOo QA-project (and I include my QA engineers into this group)
shouldn't take over the responsibility for the other products only why
they have the same name. All resources the QA-project or other OOo
projects spend into the other products are lost for the vanilla OOo. And
the QA project has limited resources. The mass of number of CWSs and the
open issues are more than enough. It is hard enough to hold the quality
of OOo.
3. It is in discussion to import all issue reports of (e.g.) Ubuntu
into IssueTracker.
Not exactly; I'd rather describe it as opening a communication channel
about linux distributions bugs; this is not about duplication of
already existing bugs that are identified in IZ.
Perhaps here are the different understandings between us. I do not
see IssueTracker as a communication channel which can help here.
I didn't either until last Thursday.... :-) But IZ can be very effective as it
displays accurate and mostly factual data.
IZ is a bug tracking tool, nothing more or less and it isn't one of
the best tools in this area.
It isn't possible to display how good or bad the quality of a product
is. We talked about this very often in the QA project. Or what do you
want to display?
I do not think it is a good idea to press different products in one
system (here Bugtracking system). It will bring more complexity in
this system. It will not bring a common visibility for the end users.
And as I understand your request correctly, this is one major part
of the discussion between your project and the Ubuntu team.
Thorsten: I was not representing "my project" but OOo and I was there
as a member of the Community Council who was on a "fact-finding"
mission together with Sophie Gautier :-)
It might bring more complexity (although we certainly can handle this
as I don't foresee the number of reports to be very important) and it
will bring a common visibility of the bugs our users are writing us
about, not knowing what's a bug tracker nor what the difference between
ooo-build and the vanilla build is. Thanks to this visibility we might
then be able to gain a better understanding of what's wrong, whether
we can help in the upstream, whether Go-OO can help or if it's just a
packager downstream doing some lousy job with our software.
I do not understand, how the bugtracking system should help to identify
the problem of the different derivatives of OOo. The issues which were
written to Ubuntu should show them the problems. If they do not know,
why they are different then the vanilla OOo and the go-ooo version, than
nobody on OOo can help anyway.
Actually this is even worse than what you think. They don't collect bugs and when they do they report it to Go-OO, but they don't care whether it is related to Go-OO, to the upstream or to the Debian patches. So in fact, both the upstream project (us) and Go-OO receive "unsorted trash" .
While there is no real excuse for a package maintainer not doing his/her job well, there is the problem of the quality management of the downstream versions that end up smacking us, the OOo project, in the face. I'm using again the case of the search bar and dialog that was not translated in the Ubuntu build: Not only had the maintainers never heard about the bug, but individual users reported it on our users list. We cannot then tell the users that it's not our fault, because the user uses OOo, not some specific versions of OOo that underwent through specific packaging that will be completely arcane to her. So in the end whether we like it or not, we have to take actions otherwise it is our adoption and our image that will be severely hampered. The good thing is, for the first time, we have our project, the Go-OO team, and the Linux distribution maintainers who are ready to work together to solve the problem.
I do not know why the OOo project should take over the quality
management for the downstream versions? Only why we have shown
that we can release products in an adequate way/quality?
Let the downstream versions do their jobs. They have to spend
resources in Quality Assurance and management. And when they
spend resources in QA, than the mother-project will benefit
from that. In the other way around the mother-project will
lose resources.
My resume is, that me should discuss only how we can address the
Issues in IZ which aren't related to vanilla OOo.
No. We should do this AND setup some new communication channels that
will integrate the feedback of distros on OOo. If it's related to the
upstream, we will have gained a bug report, if it's clearly on the side
of Go-OO, they will have gained one, and if it's a grey area then we'll
work as a team to sort this out. Besides this, I believe we can also
start to think on how we could merge Go-OO's IZ into our bugtracker.
I do not understand, why you want to integrate feedback of different
products on OOo. Is this wanted by the OOo project itself. Perhaps you
have to ask the CC about this first instead of asking the executive
QA-project first.
The CC does not get to make technical decisions unless in very special circumstances. The ESC might be more competent, but it is now asleep and in any case, this is not a decision that requires twenty different signatures.
We are not talking about different products here: we're talking about different branches of one source code, and users of these branches cannot (should not?) distinguish between them because the reason why there are different branch is at best a matter of industrial and engineering process. At the end of the day we all have to deal with the same bugs, except when there are some that are specific to each sub-version, and perhaps it might help if we could all solve them together. We all need help :-)
For me they are different products. Because the changes are so major,
that the user doesn't understand, why one product is broken and the
other one not. Therefore I wouldn't support the idea to host all
downstream products in one bug tracking system.
As I wrote. The quality of the downstream products have to be addressed
in the downstream projects. And OOo project should make pressure that
they have to increase the quality or find other solutions. The users
of OOo should have the feeling, that he use only one product on all
platforms. Therefore I do not think, that this discussion is for the
QA-project only. It has to be discussed on another level.
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qa.openoffice.org
For additional commands, e-mail: dev-h...@qa.openoffice.org
