Hello Thorsten,
Le 18 mai 2010 à 17:50, Thorsten Ziehm a écrit : > > Hi Charles, > > first of all. I'm sorry about my wording. I do not want to offend you > by using the wording 'your fr project'. I want to say only that you > started the discussion with Ubuntu in the name of the fr project. Sorry. No problem. > > Back to the discussion. Comments are in-line : > > On 05/18/10 16:48, Charles-H. Schulz wrote: >> Hello Thorsten, >> Le Tue, 18 May 2010 16:09:22 +0200, >> Thorsten Ziehm <[email protected]> a écrit : >>> Hi Charles, >>> >>> I read the thread and saw different aspects discussed here. >>> >>> 1. Your fr project and other projects got feedback about the different >>> quality of different OOo versions (distributed by different >>> companies/communities etc.) >> "My fr" project is not mine any more than it is everybody's, and it is >> my job to help every native-language project out there. Besides, it's >> not just about localization, it could affect also other parts of the >> code. > > I know, that this discussion isn't about localization. It's about > code contribution and different products with the same name. > >>> 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. > >>> 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. > >>> As I read here the products are different (different build system, >>> different patch levels ...). I couldn't understand why these different >>> products should be tracked in one system (IssueZilla). How should this >>> eliminate the different quality of the products or how should this >>> help to make the differences between the product more visible for the >>> users? >> It is not a direct effect; rather, it is by setting up an online >> communication channel we (by we I mean, OOo, the package maintainers, >> the Go-OOo tem) will be able to gradually treat the issues and identify >> structural problems (specific patches, etc.) > > Do you talk about existing issues in IZ and issues which were/will wrongly be > written in IZ? Then we are on the same side. Then we need > a mechanism to address these issues accordingly. I do talk about this BUT I do specifically talk about issues which will be brought on by OOo packagers of Linux distributions . > > But as I understand your discussion it's more than this, I'm right? Yes. It's not just about putting our IZ in order, it is about using it to connect with the downstream. > >>> Beside this Mechtilde brought up a more critical point, thanks for >>> this. The missing process for issues for other products like the >>> vanilla OOo. Currently all issues have default owners. Who should >>> be the default-owner of such issues? What about target handling? What >>> is about the status of such issues (fixed in Ubuntu build XYZ, but not >>> in OOo vanilla)? Who should check/confirm/fix the issues? ... >> well perhaps we don't have to walk all the way up to these questions at >> first. What I mean by this is that first need reporting, then we decide >> whether we want to take actions or not. But first and foremost, we need >> input. Otherwise; these are very valid questions. > > In my opinion the process has to be discussed first. As I understand > this thread correctly, I am not the only one. Yes. The full process beyond the reporting of bugs specific to whatever distribution is not determined at all yet, because the emphasis was on collecting the reports first. > >>> 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. > >>> 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 :-) Charles. > > Thorsten > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
