Hello Thorsten, Le Tue, 18 May 2010 16:09:22 +0200, Thorsten Ziehm <thorsten.zi...@sun.com> 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. > 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... > 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. > > 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.) > > 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. > > 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. > > There is still the third aspect. The number of issues in IZ increased, > which aren't related to vanilla OOo. In my eyes here we should discuss > how it can be handled. > > Mechtilde and Andre collected some thoughts : > - we need a responsible engineer (tester or developer) to set on copy > (Mechtilde named it as 'CC) to address such issues > - we need such engineers for all distros > - keywords aren't used carefully -> therefore keywords should be > avoided > - ... fully agreed. > > 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. Charles. > > Thorsten > > > On 05/15/10 14:24, Charles-H. Schulz wrote: > > Hello, > > > > (I hope it's the right list to post this message) > > > > On Thursday and Friday Sophie and I met with the Ubuntu OOo > > maintainers. The topic was how we could enhance our cooperation in > > the light of the lower quality of the Ubuntu OOo builds. We also > > had the opportunity to discuss this with the Novell/Go-OOo team and > > we believe we have come up with a global analysis and the beginning > > of the solution. > > > > Ubuntu does compile OOo from the vanilla source, using the > > ooo-build system and applying their patches in a non-systematic > > way. Which essentially means they get the worst of both > > worlds ;) ... > > > > We pointed the Ubuntu team to the various bug reports we (in the fr > > project for instance) had received and how it was unappropriate, > > unpractical and not understandable for our users to differentiate > > between builds and branches. In any case it appeared that the > > reported bugs were not easily identifiable as having their roots in > > the build system, the upstream or the patches. We have therefore > > proposed two things : > > > > - that we open a new category or subcategory on our own IZ to > > enable a direct communication of bugs and issues between Ubuntu and > > us (the upstream project) > > - that the Go-OO team moves to our own IZ and that both branches > > get a common reporting platform, a common visibility (and perhaps a > > common treatment). > > > > Your comments are welcome. > > > > Best, > > > > Charles-H. Schulz. > > > > > > > > > > --------------------------------------------------------------------- > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qa.openoffice.org For additional commands, e-mail: dev-h...@qa.openoffice.org
