[libreoffice-users] Understanding bugs / regressions / releases & more ...

Hi Paul,

        I apologize for not tackling your mail - apparently you hid most of it
after a sign off, and I didn't notice it =)

On Fri, 2014-10-03 at 00:26 +0200, Paul wrote:
> Please also understand that I don't use the feature in question, and
> until now didn't even know it was broken

        This is (perhaps) a good heuristic for determining its burning (or not)
importance vs. the other 500 or so open regression bugs (?).

> And in the general case, ignoring enhancement requests due to lack of
> developer time sounds reasonable, but then what exactly are the
> developers doing with their time right now ?

        So - developers do exactly what they want to. It is possible to try to
persuade them to do XYZ by winsome argument, challenging them in various
ways, paying them money etc. =) I do all of these from time to time.

>  Are there so many bugs that they are only fixing bugs ?

        There are enough open bugs to consume around 150 man years of straight
full-time developer time, and (as we know) they are the tip of the
iceberg - there are way more filed in the Apache bugzilla from the
legacy code. Also - in fixing them, I'd expect us to create another 50
or so man years of work - so lets see it as a round 200 man -year-
problem, and you're good. That's my estimate at least - it takes around
5 days on average to fix a bug (yes some are quick, but some are really
not) - so do the math.

        Some people look at that and say: "we should just spend 4-5 years only
fixing bugs" and then try to back that up with some co-ercive: "we
should lock down git and stop any commits that are not bug fixes" to try
to enforce that ;-) Personally I think that's only a winning strategy if
you want to loose all our volunteer (and commercial) developers that
actually do the fixing: ie. it would be completely self-defeating.

        So this is not some either/or - it is a hybrid, we try to fix the most
urgent bugs, and also improve the code quality by re-factoring to reduce
the quality impact of future changes, and we write unit tests to try to
stop bugs getting in and we also work on features.

        Either all attempts to reduce the management of an 8 million line
code-base down to a simple "this or that" type dichotomy seem pretty
doomed to failure to me =) its about trying to encourage a sensible
balance.

>  In that case are no further major revisions
> expected any time soon? I'm assuming major revisions are still planned
> for the near future, so am assuming that features are being added

        We have a time-based release schedule - which is de-coupled from any
features. If it was a sensible thing to do (and it is not) we could have
an entire release with no new features in it just bug-fixes.

        JFWIW - to get a sense of bug fixes vs. features - just read and crunch
the release notes of a summer vs. a winter release: one has a lot more
features in it because of GSOC - we spend a -lot- of our time bug
fixing.

> but where do those features come from if not enhancement requests ?

        Haha =) they come from what developers want to implement: ie. those
doing the work get to choose what to do. Some developers read
enhancement requests, most of us have a general feeling of the big
problems in the code we want to nail: some of which are really many
months of work. Of course, features are often paid for by customers of
the various consultancies working around LibreOffice - so then they get
implemented to that customers' time-line [ modulo the existing
time-based release schedule ].

>  Unless there are both feature and enhancement requests, and if so,
> please explain exactly what the difference is, and why only one of
> those is considered important right now.

        I'd see feature & enhancements as synonyms.

> And given the prices quoted for features and bugfixes, I would say
> that only the super rich can afford that sort of thing. The rest
> of us, if we're not developers, will have to wait.

        I don't really see a magic new way to fund eg. the 200 man years of bug
fixing we need (or some think we need assuming we want a zero open bug
count). Economics will ultimately win: there is no money fairy - so we
need to find some way of setting up the economics so it is sustainable;
the rest will fall into place.

> It is trying to market itself as if it isn't, as
> if it is a serious alternative. And that means it has users. And
> keeping users means at least a little pandering. 

        Its quite probable that we can improve our marketing (as we can improve
everything).

> But for most commercial projects, if the users start complaining about
> serious bugs, they sure *do* jump to it. They don't put it in a testing
> branch and do nothing with it, hoping the users will notice and test it
> for them. They fix it, test it, and roll it out to their users.

        Last I looked TDF recommended getting commercial support from a
certified provider if you're doing a commercial project. It is
unrealistic to expect volunteers to fix bugs for commercial providers on
their time-line. It is also un-realistic to expect there to be no bugs
in the software - particularly given the legacy we have. It is also
un-realistic to expect the fixes we do not to introduce regressions. It
is also un-realistic to expect none of those to 'escape'. So - perhaps
there is a new approach - but whatever it is it really needs to add-up
economically and answer the question: how can we fund -way- more
developers to work full time on improving LibreOffice. I find all
answers to that interesting, so please do share.
 
> Even if those users are whiney, demanding want-it-all-for-free's,
> they're the only users you've got.

        So - some users are a pleasure to deal with; do not have an entitlement
attitude, and are happy when/if they get a fix for their issue. Of
course, some users are as you describe, and I'm not sure it's  a
terrible shame to loose them.

> One doesn't expect old things to be broken, one just expects some new
> features to have been added and some bugs to have been fixed. And new
> bugs aren't exactly in the changelog :)

        Fixing a given bug, is quite likely to introduce a new bug, clearly the
rate is sub 100% but ... that's life in development. We have a vast and
highly-coupled code-base.

> And if one discovers a bug, well, one participates in
> the bug reporting process, and hopes it gets fixed fairly soon.

        Great.

> And that's all fine, so far. It's when things aren't fixed, and one
> starts pointing it out, and gets blamed for not being part of the
> process, and told to either pay for it, fix it yourself, or basically
> keep quiet and wait until somebody decides to get round to it, one
> starts to get a little peeved.

        So - I can understand the frustration; but what alternative is there ?
=) there is no giant pot of money to pay to fix every known bug. 200 man
years is around $4m if you hire cheap Asian developers (who I suspect
will take longer to fix each bug ;-) so say it's some $10m problem.

>  Especially when said bug is a major part
> of the application. A real show-stopper.

        We fix a ton of these before release time and during the lifetime of
the application. There are really very few show-stoppers that I've seen.
Particularly, if the issue is not found for months after release - I'm
personally skeptical that it is indeed a show-stopper: though try
explaining that to a typically angry person that found it and is
convinced it is the worst bug in the world =)

> So most of the time there is no problem here, but in this particular,
> and unusual case, the standoffish nature of the LO defenders who
> refuse to admit any culpability is not helpful.

        So - bear in mind that the vast majority if not all developers that
contribute code fix -way- more bugs than they create as an accidental
side-effect.

> The user doesn't have a problem here, at least, not for longer than it
> takes to uninstall LO and install MSO.

        From my perspective, I want LO to be better than MSO so people choose
it on its merits, not on its price. Ultimately, if people can easily
just install MSO then why not: they can use LibreOffice for those things
that its better for and MSO for what its better for - why are we
worrying about them ?

> The user isn't even complaining that LO made a mistake, the user is
> complaining that nothing is being done about it, because as far as the
> user was aware that was the case. For a major bug that was introduced
> into a working feature. And wasn't fixed for more than one major
> release. Which is a fairly bad state of affairs. And had LO said "oops,
> our bad", and promised to do something about this

        So - LO doesn't really have a corporate personality. Developers cannot
and do not read all bugs. If the bug is very serious, we expect QA to
tag it as a 'Most Annoying Bug' and then there is a better chance a
developer might look at and fix it.

> But refusing to admit even the slightest blame here, and instead trying
> to make out that this whole thing was the user's fault for expecting
> anything

        Well - it's clearly our fault if the users expect professional support
for free from LibreOffice - we screwed our marketing up =) They -may-
get professional support for free: there are a lot of professionals who
are awesome hackers who love to fix bugs for people just from the
goodness of their hearts, some professional LibreOffice developers do
this stuff in their work time (perhaps a customer filed the same thing),
and some do fixes in their spare time - but it is very far from
guaranteed.

        I tend to agree that we need to make this more clear in our bug filing
flow. Setting a clear level of expectation would be very useful to avoid
disappointment. When we have our own bugzilla we can do that.

        I see people who say things like: "I filed SIX MONTHS ago, and it's
still not fixed" (yes they shout ;-) - which again is a mismatch in
expectation about timelines and prioritization etc.

> > So leave them with a security vulnerability - Good job IT guy ;) 
>
> Well, partly that's their choice. They could pay for a bugfix, or live
> with a show-stopper, or live with a security vulnerability.

        Sure why not.

> Although, at the quoted prices, I can't blame them for not wanting
> to pay for this to get fixed. Especially when there is a lot of
> justification to the argument that if LO broke it, LO should fix it.

        So - I know nothing about other people's prices - but at Collabora we
have this crazy approach of charging the average of what it costs to fix
a bug, plus a normal consulting margin ;-) We find that charging less
than what it costs to fix is not a sustainable approach - but we're also
happy to do work under time & material terms if people think their bugs
are easy (sometimes they are in fact).

> I suppose that LO could argue that they have no responsability to keep
> the application in a working state

        Seriously; LO is in a 'working state' I use it for work every day,
intensively. We are talking here mostly about corner cases - and ones
that happen not to have broken & been fixed in the era where we write
unit tests for fixes (ie. in the LibreOffice era).

> > You can not force a volunteer
>
> No, but you can revoke their commit access.

        Same thing; you loose the volunteer. We work very hard to try to
attract volunteer developers. I hear you are a developer - would you
like to have a go ! there are plenty of Easy Hacks to get stuck into :-)
and plenty of easier bugs to fix.

>  If a dev is going to go around breaking things, and then refusing
> to fix them, he is going to cause more harm to the project than good,
> and shouldn't be allowed to play in the sandpit.

        So there are private social mechanisms that have this effect in the
developer community. But you're assuming a lot here. The first huge
chunk of work is finding out -which- developer broke something. That is
something a volunteer can do with bibisect reasonably easily; and
they're welcome to do.

> In this case that is abviously too drastic a measure, but the point
> still stands that the developer who broke it does bear some
> responsibility to fix it.

        And the developer who broke it no doubt does tend to feel that; can you
imagine the effect some of the overkill in the bug has on how they
feel ? They spent all this time implementing a new feature that was
loved by millions, and then some swine flames their ass endlessly about
some minor bug and says they should have their commit access revoked ;-)
[ not saying that happened in this case, but it is an -all-too-common-
and sad pattern in the bad bugzilla interactions I get to see ].

> And LO needs to admit that it was a rather big blunder. Those happen,
> and no-one should be trying to hang LO for it. In fact, LO being able
> to admit it would make us all feel a little more sympathetic to LO.

        We make blunders all the time =) none of them are intended with malice
to hurt our users. Indeed, we're eager to help our users help us to make
the product better: there should be a smooth ramp for getting involved
with QA, and -nothing- is hidden: all our development is in the open,
that a bug got introduced, and (after months of release candidates)
escaped into the wild is a point of shame for us all. *But* - it is also
a point of shame for those who failed to show up to test the RC's or
master snap-shots with their pet use-case IMNSHO ;-) And it is no issue
at all to point that out. There is not some magic pool of "other people"
who are to blame for a bug escaping =) its particularly ironic top blame
the very people who are trying to make things better in this regard.

> but so far no one seems to want to admit even this most obvious of
> faults on LO's part. Which means the response as a whole comes off
> as trying to shirk all guilt.

        So - I think my point here is that we're all guilty. LibreOffice relies
on volunteers.

        What I read from this thread (and was encouraged by FWIW) is that
Tanstaafl seems less upset about the issue than those trying to defend
his corner, and may well try to help-out more testing his customer's
use-case in more recent builds and so on. If that continues to happen -
we have a net win: one more much appreciated QA member.

        We will always have bugs; we will always have disagreements. The only
interesting thing is what we do with that.

        I'd like to see progress on getting more people doing QA earlier in the
cycle. That is where it is most valuable; ideally working alongside
developers in a friendly & constructive way -really- early in the
process. Sure that means reading the git commit log, playing with master
or RC builds and sending some e-mail - but I think it's worth it.
Everyone else benefits from that - and the load of doing the work to
improve LibreOffice already -heavily- weighs on the few that are willing
to make positive change in the code: anything people can do to get
involved sharing that burden is very much appreciated.

        Any my economic questions are not just for amusement: I think there is
another vital task here, which is to try to get more funding into the
ecosystem to invest it into LibreOffice in a sustainable way: I spend a
lot of time thinking about & working on that; help appreciated.

        ATB,

                Michael.

-- 
 michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot


-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted