Le Tue, 18 May 2010 14:41:27 +0200, Mechtilde <o...@mechtilde.de> a écrit :
> Hello, > > Am 18.05.2010 14:11, schrieb Charles-H. Schulz: > > Hello Jan, > > > > Le Tue, 18 May 2010 13:33:14 +0200, > > Jan Holesovsky <ke...@suse.cz> a écrit : > >> > >> Hi Charles, > >> > >> On Saturday 15 of May 2010, Charles-H. Schulz wrote: > > Thanks for that questions > > > > I have two questions here: > > - is the process you describe invariable? (I mean: do you always do > > that?) > > - to me it strikes me as being more complex than just using Go-OO or > > not. Go-OO may or may not be less stable than OOo, but what seems > > to be the real issue imho , is the combination of the following > > factors for Linux distributors or packagers: > > - choice of source: OOo or Go-OO > > - choice of build system: vanilla or ooo-build > > - patches from Go-OO and/or Debian: partial or total integration. > > In my view there are different problems. > > 1. the different build environments, not only ooo-build or vanilla. > Each distri has its own environment with some small differences. Yes, although there has to be a limit where the effort and the work comes from the distro itself; that is, there comes a point where the problem should not always be with us but with the distributor too. > > 2. the more or less missing QA-Process. > > > > > the combination of two or more of these necessary choices for > > maintainers is very much what creates most of the problem, and > > there is no easy answer. > > Because of this I want to discuss these problems so we can learn which > problems exists and try to discover some ways for better communication > > The example I usually give here is the difference in > > quality between the Ubuntu build and the *Suse build. Ubuntu is > > using the OOo source, builds it against the ooo-build system and > > applies patches from Debian and Go-OO. > > and this on an actual Ubuntu system. > > For bug reports they go to Go-OO. > > in general to their (Ubuntu) bub tracking system. > > If they analysed that this is a problem in the ooo-build then they > will/would apply it to the go-oo bug tracking system. Unfortunately they don't. Maintainers want simplicity too, and therefore we suffer from it in the end. > > We > > obviously have some inconsistency to deal with, regardless of the > > bug tracker which is being targeted :) Suse, on the other hand, > > uses Go-OO, which means its own branch + ooo-build system and its > > own patches. The quality is not as good as OOo, > > This is for me a problem of the quality management of the buids they > published Yes it is, but it comes from the fact that they take what's the most effective for them, and not necessarily what's the best for their users. > > but it is much, much better than with > > Ubuntu. So we have important differences of quality throughout Linux > > distros and users don't really care what the packagers choose, they > > just want results. > > So in my opinion we have to discuss how we can increase the quality > and decrease the differences between the diffent versions. And how we > can communicate the differences they are visible. It is a good idea. But at this stage maintainers will not necessarily move if it's too much work for them use the vanilla build system for instance. So we might want to have an accurate idea of the number of issues, of their natures and the overall "size" of the problem; then we can start to discuss the optimal solution for them. > > > > That's how I can formulate the problem, although I'm glad we > > have some form of final upstream contribution in the end. > > we (from the project) should also learn how distributions work and how > they build/maintain their versions > > >>> - 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). > > One idea to a way could be that we take the person how is responsible > for a distribution in the CC so (s)he can decide if this problem is a > distribution problem or a go-oo problem. the CC...? the Community Council? or you mean, we put in copy the maintainer of the distro? it may or may not work. We will not have solved the build issues, only make them aware they have to choose between two bug trackers :( > > We from the project are not able to decide in detail where the problem > come from. So we have to work as a team. +1 > > >> This is one of the possibilities, but rather a long term one - as > >> you know, migration is never a really fast process ;-) I have an > >> idea that might work immediately, though: > > > > Yes it does take time so let's start to think about it now :) > > > >> > >> We would create an alias like go-oo-b...@openoffice.org, and > >> anything that you identify as a go-oo only bug, you'd just > >> reassign to this alias, instead of closing it as 'invalid'. We > >> would take care of the proper assignment of the bug (all the go-oo > >> people have an IZ account too), and its solution. > > and here we have to work together to analyzed where the bug come from. > in the past time it was not so easy to motivate the people to workout > the reason of the problem. Perhaps if we bring the packagers and the Go-OO team we'll find the proper motivation. > > >> What do you think, please? > > I can't see an advantage of this alias. > > > > That certainly sounds like a good idea. Perhaps a keyword in IZ as > > well like "go-oo specific" would also be useful. I'm wondering what > > others here think about it too. > > I think better than the keywords is to know the OOo-Name of the > responsible person to take her/him into CC or assign the issue. and > then to coorporrate to do further analysation of the problem > description. It might help but they will not amend their ways just because we know them, I think. Best, Charles. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qa.openoffice.org For additional commands, e-mail: dev-h...@qa.openoffice.org
