On Fri, Apr 3, 2009 at 8:51 AM, Juergen Schmidt <[email protected]> wrote: > First of all thanks for all the issue reports. 131 issues over which period?
Our oldest issue is from May 17, 2005, so that would be almost exactly 4 years. > You heavily use OO and of course the API. > Probably for your use-cases every single reported bug was a showstopper. No. We can work around things that have never worked. It's the regressions and incompatibilities that are the problem, because they mean that a new OOo version fails where an old OOo version has worked. This messes with our deployment and updating plans, because it either forces an update of our extension on our customers or it prevents an update of OOo. In an organization with several 1000 desktops managed by 2 dozen independent IT departments, some of which are not exactly fans of this whole MS Office -> OOo migration of which our extension is a major part, this is a real bitch. > But > what do you think. Are they showstopper issues for all others as well or are > they more normal issues where we have thousands from? How many issue would > be P1 or P2 taking the OO.org issue guide lines into account? Priorities always depend on which market is most important to you. If you're looking at the millions of ordinary people who need little more than the feature set of WordPad, your priorities are going to be different than when you look at power users who depend on 3rd party extensions. I think that ATM the OOo developers do not give enough importance to 3rd party developers. MS Office is an important ecosystem. Lots of other applications interface with it and depend on it. Companies have built businesses around 3rd party extensions to MS Office. I believe that unless something significant changes in the attitude of OOo's main developers, OOo will NEVER be such an ecosystem. IMHO we are heading towards a future where OOo beats MS Office in market share of the consumer market, simply because shipping OOo with a PC costs the PC vendor nothing and OOo is good enough for consumers. However in the professional market, OOo will not ever beat MS Office unless more effort is put into helping 3rd party developers. > > The bootstrap change was necessary because of the new structure I disagree. Keeping old registry keys and old directory structures around for compatibility (possibly redundant, possibly for a limited time, coupled with a deprecation warning) was a possibility. Not a pretty one, maybe, but a possibility. Furthermore it can be argued that the new structure itself was not necessary or could have been implemented in a different way (again possibly not as pretty from a technical POV). But let's not argue about implementation details. It's beside the point. My point is that there was not even an effort to maintain compatibility by the OOo developers. I have a problem with the attitude that breaking each and every external app using the old boostrap code was okay, with no grace period, simply because 3.0 was a new major version. > and a > rebuild including the newer bootstrap glue code solved the problem. Tell that to customers who have BOUGHT a binary-only application whose vendor charges for an update or worse has stopped maintenance of the application altogether. Now you may argue that there are very few for-pay 3rd party apps interfacing with OOo and that's probably true, but is that a good thing? Don't we want OOo to be an ecosystem to build applications and businesses around? > What exactly do you mean with the classloader change? I am not 100% sure > what you mean. I think we never ever have defined that all jars in the > classes directory are in the classpath. IIRC, our problem was with the JAR for our extension itself. Anyway, neither was it defined that this would not be the case. And AFAIK there was never documentation about how to handle class loading from extensions properly. > That was an implementation detail. That's a typical shift-the-blame argument. You cannot develop useful applications relying only on published interfaces and documented behaviour. The documentation is much too incomplete for that and many necessary interfaces are unpublished. Again it boils down to an attitude problem. You are technically 100% right. But that you "have the right" to break something doesn't mean that you should do it. It especially doesn't mean that you should do it from one minor release to another with no notice, no grace period and no option to keep the old behaviour. I would never dare take your freedom away to make changes to implementation details for technical reasons, but there are ways to minimize the pain such changes inflict on affected parties. But right now, such things do not seem to be considered by OOo developers. As I've said multiple times already, it's a matter of attitude and I think yours needs to change if you want OOo to be more successful in the marketplace. Yes, Microsoft has broken compatibility a lot of times, but at least to the best of my knowledge they have a strong COMMITMENT to backwards compatibility. They often sacrifice technical prettiness to include compatibility crutches. They are often mocked for it, but it's a commendable attitude IMHO. And it's a very smart attitude from a business-perspective. > > i do not disagree. Well a build problem is of course bad but hey it is fixed > asap in the next version, right? Probably, but on the road to 3.1 there were so many problems I had of different kinds that at some point I was just fed up with it and said "I will not touch this again until they are in RC stage!" > Anyway the more difficult problem is that > you build the office on your own and many things can go wrong. I don't say > that you build wrong but i see a problem here. I would suggest that you use > first official dev snapshots. But i am not sure, building it on your own > should work also. Using official snapshot would maybe a little bit easier > for all We do sometimes use official snapshots, but this is always suboptimal, because they lack the patches that we apply to our builds. These patches mostly affect system integration but there are also backported bugfixes. > i understand that and good bug reports are highly appreciated. But if you > don't have time to produce a test case you can at least report the problem > on the mailing list. Maybe others had the problem and already submitted an > issue. I do that when it's appropriate. However the really hard ones are always the issues involving our own extension and unless analysed in more detail these won't ring a bell with anyone. > >> think to myself: "Well, they know that their code is broken. There's >> no need for me to waste my precious time constructing test cases for >> bugs they are probably already aware of." > > mmh, i agree that milestones should have ideally a reasonable quality and > that the trunk should be also in a good shape. But your last sentence > irritate me, do you think that this is the way how open source should work? This has nothing to do with open source. Very often open source projects and commercial entities alike explicitly state that they do not want bug reports for a pre-release or beta version because they know that it's broken and they're still fixing bugs right and left, so there's no point to a bug report. In fact it was stated in this very thread that I shouldn't expect trunk to even build, IOW that this is not something exceptional. Constructing a test case for a known problem is a waste of time as is examining a bug that turns out to have been reported already. And even asking on the mailing list "Is this issue known?" is a nuisance because I have to at least spend the time to phrase my problem accurately (which always requires some analysis work) and to watch for replies and possibly reply again. All of this takes time that I will only invest if I feel that it's worth it. Note the word "feel". This is nothing rational. I am not a machine. I often do not feel that this effort is worth my time. While you can try to change this with words, improving the development process to focus more on quality at all times, is the only thing that will truly have an effect on me in this regard. I love working to make to a good product better. I hate working to make a broken product less bad. Matthias --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
