Hello Thorsten, Le 19 mai 2010 à 10:19, Thorsten Ziehm a écrit :
> > 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. Because they don't have the necessary resources and they don't have the skills. Plus, it's very much unclear whether these are always distro-specific bugs, that's part of what we're trying to discover. > > 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? So let's reason this way. You make sure the QA is done for Solaris, we'll take care of the other platforms and we'll check what will happen in terms of adoption, whether it's your project or ours. Frankly speaking, at the end of the day our users do not want to hear that these are "different products". We're multi-platform and open source for a reason, and this is something we have to take care of. But it does not mean to do the job of maintainers. It means try to work together to solve issues that in the end will only improve OOo and its experience. > > 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. Sorry, perhaps it's unclear: Nobody has requested to have your team work on quality assurance for Ubuntu or Canonical. That's not what is wanted here. What is at stake is to provide a common platform for bug triage and analysis. I can tell you that if it's a distro specific bug, it will be up to the distro to fix it. If it's related to the ooo-build system it will be up to the ones in charge of this build system. If it's upstream only, it'll be up to us. And if it's grey, then we should at least take the time to clarify the problem as a team. > We all cannot make pressure on Ubuntu or > Go-oo to fix an issue. They released and will release their products > anyway. Yes, and we won't pressure anyone, but we'll make sure everyone is responsible for bugs whose reports were lost in various pipes before. > 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? Again, we don't take over the work, we clarify who should be doing it. But as a side comment: OOo's a commodity. Everyone should contribute to it. You work to make sure that Oracle Open Office (sic) makes some money, Matthias Klose works to make sure Ubuntu provides a great experience and OOo is part of it, and so does Kendy for Novell's Go-OO, but at the end of the day, we all contribute to our mother project or whatever you want to call it, and it's OpenOffice.org. So it's not OpenOffice.org vs. Ubuntu's build. It's us in upstream and the others downstream, but we all need each other. > > 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. See above. > >>>>> 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? Bugs. But I'm open if you have any other idea for a platform that could do the job. > >>>>> 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. I agree with you: so what is only proposed here is to make sure we report the bugs in the same room, but in separate dashboards. What this does is that it avoids duplication of efforts, lack of information, and we get to know what the others do. We don't do the homework of the others. But at least we make sure we won't have to deal with disgruntled users who will complain to us for bugs we don't have. > >>>>> 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. I agree with you, but unfortunately it's not the case (and I don't fingerpoint anyone here) > Therefore I do not think, that this discussion is for the > QA-project only. It has to be discussed on another level. Which one? Charles. > > Thorsten > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qa.openoffice.org > For additional commands, e-mail: dev-h...@qa.openoffice.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qa.openoffice.org For additional commands, e-mail: dev-h...@qa.openoffice.org
