[Libreoffice] [REVIEW] Oracle Report Builder corrupting chart objects

[Michael Meeks]

Hi Alex,

	First - your support is appreciated :-) don't think I'm saying it is
not.

On Tue, 2011-05-17 at 15:14 +0200, Alexander Thurgood wrote:
> I think the point that most users are making is that it actually used to
> work, and was fairly stable, "in previous times". This is what people
> are concerned about, when they hear that something which used to work
> and is deemed important to that group of users no longer does because
> someone else made a change somewhere to another corner of the edifice
> that is now hard to track down and it is suggested as a result to
> potentially remove or deactivate that whole feature.

	So - this is always a problem with software. Unfortunately, if we never
change the software again, it will still loose quality - since the
underlying platforms we run on change and break over time. So what can
we expect; griping aside - if there is a better way to do things - we
need a constructive suggestion of how that works.

>  It also belies the ease (and a common open source fallacy) with which
> we are led to believe that changes can be reverted in source code once
> they have occurred, as you yourself have just stated.

	If I promise to revert a change if people don't like it - then that is
one thing; I'll do the work - that is easy enough. I can't personally
promise to fix all possible regressions - that is not reasonable, and I
assume you're not asking for that :-)

	Worse, as above, not all changes are easily revert-able; this takes
development time. Developers work on what they care about, particularly
volunteers. Users in contrast get to revert to the previous released
version, or not use the software - any of which has knock-on issues.

> The "if you want it fixed, help thyself" mantra only works for a very
> limited subset of people.

	Sure - which is the subset we have on this list :-) Having said that,
good, clear bug reports are a very helpful part of providing good
feedback, and I appreciate your work there. However, there is no
guarentee that a bug will be fixed to your liking - sorry.

> those who have become disenchanted will become the most vociferous 
> opponents of the whole project, and they are often the ones who
> prescribe or manage IT implementations in companies and administrations.

	So - I am pretty fed up of hearing about masses of people that have all
these enterprise level stability needs, but apparently are unwilling to
close the gap between their requirements and the software, by helping to
fund development: even indirectly via a support contract with someone -
anyone.

> Personally, I don't think users can ever be truly satisfied with
> software

	Too true :-)

> but one can manage their expectations. Announcements of the
> kind where one developer says "this is unstable, and it is giving me
> jip, I would like to get rid of it" when the "it" in question has been
> part of the whole product for the last 5 years, is necessarily going to
> elicit wild reactions and passionate speeches from those for whom the
> "it" has been the cornerstone of their use of the product.

	Sure :-) But I would hope for more than wild reactions and passionate
speeches - at least, those belong on the discuss list. What about some
people to help out trying to fix it: perhaps by testing the latest beta,
filing good bugs, and combining them together into an 'ORB is buggy'
tracker bug - or something. As it is - we only have 100% hearsay which
is no basis to make any decision on. If we have crashers - they are
often fairly easy to fix - lets get the bugs filed, the traces with good
debugging symbols generated, prioritised etc.

> if those tools fail to even maintain the status quo of functionality
> before I joined this "brave new world", then I will swap them for 
> another which does.

	Very sensible. Incidentally - I imagine that we imported this bug by
accident as part of the Oracle code merge, so I suspect it is a truly
professional, full-time bug ;-)

	Anyhow - what serious change to the project, our methodology,
customers, or anything else can you propose to avoid bugs getting
created ?

	My personal take is that we need to catch bugs earlier - this makes
them -much- cheaper to fix, and also throttles the pace of less
experienced programmers breaking stuff ;-) To do that we need daily
snapshots. We didn't have those working well in the 3.4 cycle - so now
we get a lot of bugs at the end; c'est la vie. Of course, more than that
we need people to use the snapshots and report problems.

	So. I don't really see any truly worthwhile ways to improve from where
we're at. We appear to have several requirements:

	* extremely high quality enterprise quality
	* substantial legacy / over-extended feature depth everywhere:
	  ie. never loose a feature only add them.
	* shipping on a predictable schedule
	* absolutely zero cost - especially for business users
	* an accelerating pace of development, via a growing community
	* community support that instantly fixes business users' bugs
	* preferably all existing, known bugs fixed
	... and more ...

	Apparently, we can't meet all these perfectly. I know what balance I
prefer - I think our processes will get us closer to them.

	Having said all that - as of today, we still ship ORB - and I don't see
that changing for 3.4: but this is clearly a wakeup call to get some
solid QA done on it.

	The great thing about this mail of course is that it took me half an
hour to write - and a chunk out of all the developers reading it's. And
all for a feature that we are not seriously discussing removing
anyway ;-)

	ATB.

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot